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Abstract. The industrial robot’s principal advantage over traditional automation is 
programmability. Robots can perform arbitrary sequences of pre-stoied motions or 
of motions computed as functions of sensory input, This paper reviews requirements 
Tor and developments in robot programming systems. The key requirements For 
robot programming systems examined in tine paper are in tins areas of sensing world, 
modeling, motion specification!, flow of control, and programming support. Existing 
and proposed robot programming systems I'alS into three broad categoriesr guiding 
systems in which the user leads a robot through the motions to be performed, 
rotooF-level programming systems in width the user writes a computer program 
specifying motion nod sensing, and task'level programming systems in which the 
user specifies operations by their desired effect on objects. A representative sample 
of systems in each of these categories is surveyed in the paper. 
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1, Introduction 


The key character]gt,ic of robots Ls versatility; they can be applied 1 a a large 
variety of casks without significant re-design. This versatility derives from the 
generality of the robot's physical structure and control, but it can be exploited 
only if the robot can be programmed easily- In some cases, the lack of adequate 
programming tools can make some tasks impossible to perform, In other cases, 
the cost of programming may be a significant fraction of the total cost of an 
application. For these reasons, robot programming systems play a crucial role in 
robot development. This paper outlines some key requirements of robot programming 
and reviews existing and proposed approaches to meeting these requirements, 

I.In Approaches to robot programming 

The earliest and most widespread method of programming robots involves 
manually moving the robot to each desired position, and recording the internal joint 
coordinates corresponding to that position. In addition, operations such as dosing 
the gripper or activating a welding gun are specified at some of these positions. The 
resulting "pre&^n 1 "' is a sequence of vectors of joint coordinates plus activation 
signals for external equipment. Such a program is executed: by moving the robot 
through Lb l l specified sequence - ! oT joint cuurdinates and issuing the indicated signals. 
This method of robot programming is usually known as teaching showing; 
in this paper we will use the less common, but more descriptive, term yutdlm? 
jGro-HSJuam 77]. 

Robot guiding is a programming method which is simple to use and to 
implement. Because guiding can be implemented without, a general purpose 
compuLer, it was in widespread use for many years before it was cost-effective 
to incorporate computers into industrial robots. Programming by guiding has 
some important limitations, however, particularly regarding the use of sensors. 
During guiding, the programmer specifies a single execution sequence for the 
robot; there arc no In ops, conditionals, or computations. This ls adequate for some 
applications, such as spot welding, painting, and simple materials handling. In other 
applications, however, such as mechanical assembly and inspection, one needs to 
specify the desired action of Uiu robot in response to sensory input, data retrieval, 
or computation. In these cases, robot programming requires the capabilities of a 
general-purpose computer programming language. 

borne robot systems provide computer programming languages with commands 
to access sensors and to specify robot motions. We refer to thene as dpiictf or 
robot-level languages. The key advantage of robotdevel languages is that they 
enable the data from external sensors, such as vision and forte, to be used in 
modifying the robot's motions, Through sensing, robots can cope with a greater 
degree oF uncertainty in the position of external objects, thereby increasing their 
range uf application. The key drawback oF robot-level programming languages, 
relative to guiding, is that they require the robot programmer to be expert in 
computer program ruing and in the design oF sensur-basedl motion strategics. EI cute, 
rubotdcvcl language are not accessible to the typical worker on the factory floor. 
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Marty recent, apppoacke- 1 ; Lu robot programming seek to provide the power of 
robot-level languages withuut requiring programming expertise. One approach is 
to extend the bask philosophy of guiding to include decision-making based on 
sensing. Another approach, known as task-levei programming, requires specifying 
goals Tor the positions of objects, rather than the motions of the robot needed 
to achieve those goals, In particular, a task-level specification is meant to be 
completely robots independent;: no positions or paths that depend on the robot 
geometry or kinematics are specified by the user. Task-level programming systems 
require complete geometric mod da or the environment arid of the robot as input; for 
this reason, they are Asa referred to as tinjrld-modefmg systems. Neither of these 
approaches is as developed as the guiding and robot-level programming approaches, 
however 

1,2. Goals or this paper 

The goals of this paper are twofold; one, to identify Qie requirements. for 
advanced robot programming systems, the other to describe the major approaches 
to the design of these systems. The paper is H*>.f meant to be a catalog, of ail existing 
robot programming systems. 

A discussion of the requirements for robot programming languages is not 
possible without some notion of what the tasks to be programmed will be and 
who the users are. The next section will discuss one task which is likely to he 
representative of robot Lasts in Lhc near future. We will use this task to motivate 
some of the detailed requirements later in the paper. The range of computer 
sophistication of robot users is large, ranging From factory personnel with zero 
programming experience to HhD's in computer science. It is a fatal mistake to 
use this fact to argue for reducing the basic function silly of robot programming 
systems to that accessible! to the least sophisticated user. Instead, we argue that 
robot programming languages should support the functional requirements of its 
mnst sophisticated users. The sophisticated users can implement special-purpose 
interfaces, in the language itself, for the less experienced users. This is the approach 
taken in the design of computer programming languages; it also echoes the design 
principles discussed in [Taylor, Summers, and Meyer S2], 
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Figure !- A representative robot application 



2. A robot application 

Figure 1 illustrates a representative robot application, The task involves two 
robots cooperating to assemble a puc]jp. Parts arrive, rail Jo roly uricr] ted and in 
arbitrary order, on two moving conveyor belts. The robot system perform a the 
following Tu Bid Lions: 

1 Determine the position and orientation qF the parts, using a vision systejn- 

2. Grasp the parts on the moving Nits. 

3. Place each part on a fixture, add it to the assembly, or put it aside for 
future use, depending on tlit state of the assembly. 

The following sequence is one segment of the application. The task is to grasp a 
cover on the moving belt, place it on the pump base, and insert four pins so as to 
align the two parts. Note the central role played by sensory information, 

t. Identify, using vision, the (non-overlapping) parts arriving on one of the 
belts, a pump cover in this case, and determine its position and orientation 
relative to the robot. During this operation, inspect the pump cover for 
de Tecta such as missing 1 boles or broken labs. 

2r Move RQ-BQT1 to the prc-spccified grasp point fur the cover, relative to the 
covers position and orientation as determined by the vision system. Note, 
that if the belt, continues moving [luring the operation, the grasp point 
will need to be updated using measurements of the belt's position. 

3. Grasp the cover using a programmer-specified gripping force. 
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4. Test the measured huger opening against the expected opening at the 
grasp point. If it js not within the expected tolerance, signal an error. 
This condition may indicate that the vision system or the control system 
are inaJfunctioning. 

$. Place the cover on tj-it base, by moving to an approach position above 
the base and moving down until a programmer-specified upward force is 
detected by the wrist force sensor. During tbe downward motion,, rotate 
the hand so as to milt out any torques exerted on the cover because of 
misalignment of the cover and the hase. Itelease the cover and record its 
current position For future use, 

6. In parallel with the previous steps, move R0BCIT2 to acquire an aligning 
pi» from the feeder. Bring the pin to a point above the position of the first 
bole in the cover, computed from the known position of the hole relative 
to the cover and the position of the cover recorded above. 

7. Insert the pin. One strategy for this operation requires tilting the pin 
slightly to increase the chances of the tip of the pm falling into the bole 
|Inoue 71, 74]. IT the pin docs not fall into the hole, a spiral .search can 
be initiated around that point [Goto SO, Taylor 7(5]. Once the tip of the 
pin is. seated in the hole, the pin is straightened. During this motion, the 
robot is instructed to push down with a pro-sped tied Force, to push In 
the t/ direction (30 as to maintain contact with the side of the hole), and 
move so as to null out any forces in the x direction (Immae 74], At the end 
of this operation, the pin position is tested to sneer tain that it is within 
tolerance relative Lo the computed hole position. 

$_ In parallel with the insertion of the pin by ROBOTS, KtlBUT 1 fetches another 
pin and proceeds with the insertion when R0BQT2 Is done. This cycle is 
repeated until all the pins are inserted- Appropriate interlocks must be 
maintained between the robots to avoid a collision. 

This application makes use of four types oF sensors: 

1. Direct position sensors. The internal sensors., e.g. potentiometers, or 
incremental encoders, in the robot joints and in the conveyor belts are 
used to determine the position of the robot and Lhe belt at any instant of 
time. 

2. Vision sensors. The camera above each belt is used to determine the 
identity and position of parte arriving an the belt and to inspect them- 

3. tQVC-h sensors. Sensors in the lingers are used to control the 
magnitude of Llic gripping force and to detect the presence or absence of 
objects between the fingers. 

4. IVWsi force sensors. The positioning errors in the robot, uncertainty in 
part positions, errors in grasping position, and part tolerances all conspire 
to make it impossible to reliably position parts relative to each other 
accurately enough for tight tolerance assembly. It is possible, however, to 
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use the fbrr-cs generated as the assembly progresses to suggest incremental 
motions that will achieve the desired final state; this is known as cempliant 
motion! e,g., [Mason Si). 

Most- of this application is possible today with commercially available robots and 
vision systems. The exceptions are in the use of sensing, The pin insertion. For 
example„ would be done today with a mechanical compliance device |Whitney 
82; specially designed for this type of operation.. Techniques For implementing 
compliant motion via force feedback are known, e.g,, (Paul 81, Raibert and 
Craig Si, Shimano 78); but current force feedback methods arc not as fast or as 
robust as mechanical compliance devices, Current eornmeociaJ vision systems would 
also impose limitations cm the task, e.g., parts most not be touching. Improved 
techniques for vision and compliance are key areas of robotics research. 
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Z. Requircmeris of robot programming 


The task described above illustrates the majr>r asserts of sophisticated robot 
programming: sensing world model]tig, motion specification, and flow of control, 
This section discusses each of these issues and their impact on robot programming. 

3.1- Sensing 

The vast majority uf‘ current industrial robot applications are performed using 
position control alone without significant external sensing. Instead h the environment 
]S engineered so as to eliminate all significant sources of uncertainty, All parts are 
delivered by feeders, for example, so that their positions will be known accurately 
at programming time. Special purpose devices are designed to compensate for 
uncertainty in each grasping or assembly operation, This approach requires large 
investments in design time and special-purpose equipment Tor each new application. 
Because of the magnitude of the investment, the range of profitable applications is 
limited; because of the special-purpose nature of the equipment, the capability of the 
system to respond to changes in the design of the producL or in the manufacturing 
method is negligible, Under these conditions, much of the potential versatility of 
robots is wasted. 

Sensing enables robots to perform tasks in the presence of significant 
environmental uncertainties without special purpose tooling. Sensors can be used to 
identify the position of parts, to inspect parts, to detect errors during manufacturing 
operations, and to accomodate to unknown surfaces. Sensing planes two key 
requirements on robot programming systems, The First requirement is to provide 
general input and output mechanisms for acquiring sensory data. This requirement 
can be met simply by providing the I/O mechanisms available in most high-level 
computer programming languages, although this has seldom been don®. The second 
requirement is to provide versatile control mechanisms for using sensory data 
to determine robot mo Lions. This need to specify parameters for sensor-based 
motions and to specify alternate actions based on sensory conditions is the primary 
motivation for using sophisticated robot programming languages, 

Sensors are used Tor different- purposes in robot programs, each purpose has 
a separate impact on the system design. The principal uses of sensing in robot 
programming are: 

1. Initiating and terminating motions. 

2. Choosing among alternative actions. 

3. Obtaining the identity and position qT objects and features of objects. 

4. Complying to external constraints. 

The most common use of sensory data in existing systems ia to initiate 
and terminate motions. Most robot programming systems provide median inrun For 
waiting for an external binary signal bcForc proceeding with execution of a program. 
This capability is used primarily to synchronise robots with other machines. One 
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common application of tliis capability arises when acquiring parts From feeders; the 
robot/s grasping motion in initiated when a light-beam is interrupted by the arrival 
of a new part at the Feeder. Another application is that of locating m imprecisely 
known surface by moving towards it and terminating the approach motion when 
a micro-switch is tripped or when the value of a force sensor exceeds a threshold. 
This type of motion is known as a guarded move [Will and Grossman 75] Guarded 
moves can be used to identify points on the edges of an imprecisely located object 
such as a pallet. The contact points can then be used to determine the pallet’s 
position relative to the rnbot and supply offsets for subsequent pick-up motions. 
Section 4.1.2 illustrates a limited form of this technique available within some 
existing guiding systems. General use of this technique requires computing new 
positions on the basis of stores values; hence it is limited to robot-level languages. 

The second major use or sensing is in choosing among alternative actions in 
a program. One example is deciding whether to place an object in a fixture or 
a disposal bin depending on the result of an inspection test. Another, far more 
common, example arises wlien testing whether a grasp or insert action had the 
desired effect and deciding whether to take corrective action. This type of error 
checking accounts for the majority of the statements in many robot programs.. 
Error checking requires the ability 1.0 obtain data from multiple sensors, such as 
visual, force, and position sensors, to perform computations on the data, and to 
make decisions on the results. 

The third major use of sensing in robot systems is in obtaining the identity 
and position of objects or features of objects. For example in the application, 
described earlier, a vision module is used Lo identify and locate objects arriving 
on conveyor belts. Because vision systems are sizable programs requiring large 
amounts of processing, they often are implemented in separate processors. The 
robot program must he able, in these cases, to interface with the external system 
at the level of symbolic data rather than at the level of "raw" sensory data. Similar 
requirements arise in interfacing to manufacturing data bases which may indicate 
the identity of the objects in different positions of a pallet, for example. From these 
considerations we can conduce that robot programming systems should provide 
general input/output interfaces, not ju&t a Few binary or analog channels as is the 
rule in today’s robot systems. 

Once the data from a sensor or database module is obtained, some computation 
must be performed on the module's output so as to obtain a target robot position. 
For example, exisiting commercial vision systems can be used to compute the 
position of the center of area of an object's outline and the orientation of the line 
that minimizes the second moment. These measurements arc obtained relative to 
tlie camera’s coordinate system. Before the object can be grasped, these data must 
be related to the robot’s coordinate system and combined with information about 
tiie relationship of the desired gTasp point to the measured data (see section 3.2), 
Again, this points out the interplay between the requirements for obtaining sensory 
data and for processing it. 

The fourth mode of sensory interaction, active compliance, is necessary in 
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situations requiring continuous nation in response to continuous sensory input 
Data From force, proximity, nr visual sensors can be used to modify e,1jc robot's 
motion so as to maintain or achieve a desired relations]]ip with other objects. 
The forcc eoritroJkd motions'to turn a crank, for example, require that the target 
position nr Lhe robot from instant Lo instant be determined from the direction 
and magnitude of the forces acting on the robot hand, e-g., [Mason SI, Paul and 
Shimanu 76], Other examples are welding on an incompletely known of moving 
surface, And inserting a peg in a hole when the positinn uncertainty is greater 
than the clearance between the parts. Compliant motion is an operation specific to 
robotics; it requires special mechanisms in a robot programming system. 

There are several techniques for specifying compliant motions, for a review see 
[Mason S3]. One method models the robot as a spring whose sLiffbcsses along each 
of the six motion freedoms can be set- lll&fiafu&a and Asada 77, Salisbury 80], This 
method ensures that a linear relationship is maintained between the force which 
iii sensed and the displacements from a nominal position along each of the motion 
freedoms. A motion specification of this type requires the following information: 

1. A coordinate frame in which the force sensor readings are to be resolved, 
known as the cofulraini /ruT/tfl. Some common alternatives arc: a frame 
attached to the robot hand, a fixed frame in the room, nr a frame attached 
to the object being manipulated,. 

2. The desired position trajectory of the robot. This specifies the robot's 
nominal position as a function of time. 

5, StiFfncsses for each of the motion freedoms relative to the constraint frame, 

For example, a high stiffness for translation along the z axis means that 
the robot wilt allow only small deviations from the position specified in the 
trajectory, even if high forces are felt in the. a direction. A low stiffness, on 
the other hand, means that a small force can cause a significant deviation 
from the position specified by the trajectory. 

The specification of a compliant motion for inserting a peg in a hole [Mason B3] i.a 
as follows: 


The constraint frame will be located at the center of the peg’s bottom surface, 
with its z~axis aligned with the axis of the peg. The insertion motion will be a 
linear displacement, in the negative z direction to a position slightly below the 
expected final destination, nf ibe peg. Figure 2 illustrates the coordinate system 
and planned insertion motion. 

The stiffnesses arc specified by a matrix relating the robot’s position parameters 
to the force sensor inputs: 


r= ka 

where f is a 6 X 1 vector of Forces and torques, K is a S X 6 matrix of stiffnesses, and 
A is a G X l vector of deviations of the robot from its planned path- While inserting 
a peg in a hole, we wish the constraint frame to follow a trajectory straight down 
the middle of the hole, huL complying with forces along the x- and y axes and 
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Figure 2. Peg-in-hole insertion illustrating coordinate system smd nominal path. 



with torques about the i- and jr-axes. The stiffness matrix K Fur this task would 
be a diagonal matrix 

K EH , k Ql itojJti) 

where &q indicates low stiffness and a high stiffness 1 . 

The complexity of specifying the details or a compliant motion argues, for 
introducing special-purpose syntactic mechanisms into robot languages, Several 
such mechanisms have been proposed fur different compliant motion) types |Mujtaba 
and Goldman TS, Paul and Shimano 7S. Paul SL, Salisbury 80j. 

One key difference between the first three sensor interaction mechanisms 
and active compliance is extensibility. The first three methods allow new sensors 
and modules to be added or changed by the user, since the semantics of the 
senior is determined only by the n&er program. Active compliance, on the other 
hand,, requires much more integration between the sensor and the motion control 
subsytem; a new type of scn&or may require a significant system extension. Ideally, 
a user’s view of compliant motion could be implemented in terms of lower-level 
procedures in the same robot language. Sophisticated users could then modify this 
implementation to suit new applications, new sensors, or new motion algorithms. 
In practice, efficiency considerations have ruled out this possibility since com pliant 
motion algorithms must be executed hundreds of times a second 5 . This is not a 
fundamental restriction, however, and increasing computer power, together with 
sophisticated compilation techniques, may allow future systems to provide this 
desirable capability, 

'Unfortunately, the numeric-id choices for difTnruct are dictated by detailed -considerations of 
characteristics of the environment and of the control eyatcni |Wliitnej 77, Huiafuea mid Auuta. 
7?| 

^{Gcsdike 76| describes a robot KjsU-m architecture that enabler different aenaora to be interfaced 
into the motion control subsystem from the user language level See aJao |Taut 31 j For a different 
proposal. 
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In summary, we have stressed the need for versatile input/ouLput and 
computation mechanisms to support sensing in robot programming systems, The 
most natural approach for providing these capabilities is by adopting a modern 
high-level computer language as the basis for a robot programming language. We 
have identified one sensor-based mechanism, namely compliant motion, that requires 
specific language mechanisms beyond those, of traditional computer languages, 

irt addition to the direct mechanisms needed to support sensing within robot 
programming languages, there are mechanisms needed due to indirect effects of the 
reliance on sensing for robot programming. Some uT these effects arc: 

I. Target positions are not known at programming time; they may be 
obtained from an external database or vision sensor or simply be defined 
by hitting something. 

2 The actual path to be followed is cot known at programming time; it may 
be determined by the history of sensory inputs. 

3. The sequence of motions is not known at programming time, the result of 
sensing operations will determine the actual execution sequence. 

These e fleets of sensi n g have sign ifi cant i in pact on the stru ctu re of robot program m in g 
systems. The remainder of Lb it section explores these additional requirements. 

3.2. World modeling 

Tasks that do not involve sensing can be specified as a sequence of desired 
robot configurations; there is ilo need to represent the geometrical structure of the 
environment in terms of objects. When the environment is not known a priori, 
however, some mechanism mu&t be provided for representing the positions of objects 
and their features, such as surfaces and holes. Some of these positions are fixed 
throughout the task,, others must be determined from sensory information, and 
others bear a fixed relationship with respect to variable positions. Grasping an 
object, for example, requires specifying the desired position of the robot's gripper 
relative to the object's position. At execution time, the actual object position is 
determined using a vision system or on-line database. The desired position for 
the gripper can be determined by composing the relative grasp position and the 
absolute object- position; this gripper position must then be transformed to a 
robot configuration. A robot programming system should facilitate this type of 
computation, on object positions and robot configurations. 

The most common representation foe object pnsi Lions in robotics and graphics is 
the homogeneous transform, represented by a A X 4 matrix jF’aii] 81]. A homogeneous 
transform matrix expresses the relation of one coordinate Frame to another by 
combining a rotation oT the axes and a translation of the origin. Two transforms can 
be composed by multiplying the correspond ing matrices. The inverse of a transform 
which relates frame A to frame B is a transform which relates B to A. Coordinate 
[Yames can be associated with objects and features of interest in a task, including 
the robot gripper or tool. Transforms can then be used to express their positions 
with respect to one another. 
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Figure A, VVurld model wilt coordinate frames 





A simple world model, with indicated coordinate frames, is siiown in Figure 3, 
The task is S-d visually locate the bracket on the table, grasp it, and insert- the pin, 
held in a stationary fixture, into the bracket's hole. The meaning of the various 
transforms indicated iin Lhe figure arc as follows. Cam is the transform relating the 
camera frame to the WOULD frame. Ot&sp is the transform relating the desired 
position or the gripper’s frame to the bracket's Frame. Let Bracket be Lhe unknown 
transform that relates the bracket frame to WORLD. We will he able to obtain 
from the vision system the value of Bk H, a transform relating the bracket’s frame 
to the camera's frame 3 . Hole is a transform relating the hole's frame to that of the 
bracket. The value of Hole is known from the design of the bracket. Pin relates 
the frame of the pin to that of the fixture. PiaPrre, in turn, relates the fixture's 
frame to WORLD- % relates the frame of the robot base to WORLD. Our goal is 
to determine the transform relating the end-effector's (gripper's) frame, E t relative 
to the robot’s base. Given L and Z, the robot's joint angles can be determined 
[set, for oxxmplCf [Fan I *!]>■ 

The first step of the task is determining the value of Bracket, which is simply 
Cam [ikt. The desired gripper position for grasping the bracket Is: 


''tiling only one camera we cannot determine the distance tram the camera to the hiackrt 
directly. We aaaiime instead: Lli:*.t die diitaiico to the labia is known. 
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Z E = Bracket Grasp 

Since Cam is relative to WORLD, Bkt relative to Cam, and Grasp relative to 
Bkt, the composition. gives ns the desired gripper position relative to WORLD, l.e., 
Z E- At the target position we want the location of the hole relative to WORLD 
to be equal to that of the pin; this relationship can he expressed as: 

BracfceF Hole = Fiiture Fin 

From this we ran sec that 

Bracket = Fixture Fin Hole~ l 
Hence, the new gripper location is; 

Z F ^ Fixture Fin H olc^ 6 Ora up 

The uk of coordinate frames to represent positions has two drawbacks.. 
One drawback is that a coordinate Frame, in general, does not speedy a robot 
configuration uniquely. There may be several robnL configurations that place the 
end-effector in a specified frame. For a robot with six independent motion freedoms, 
there arc usually on the order of eight robot configurations to place the gripper at 
a specified frame. Some frames within the robot’s workspace may be reached by 
an infinite number of cacdigurations, however. Furthermore, for robots with more 
than six motion freedoms, the typical coordinate frames in the workspace will be 
achievable by an infinite number of configurations. The different configurations 
that achieve a frame specification may not be equivalent; some configurations, for 
example, may give rise to a collision while others may not. This indeterminacy needs 
to be settled at programming time, which may be difficult Tor frames determined 
from sensory data. 

Another, dual, drawback of coordinate frames is that theyTnay overspecify 
a configuration. When grasping a symmetric object such as a cylindrical pin, for 
example, it may not be necessary to specify the orientation of the gripper around 
the symmetry axis. A coordinate frame will always specify this orientation, however. 
Thus, if the vision system describes the pin's position as a coordinate frame and 
the grasping position is specified likewise, the computed grasp position wilt specify 
the gripper’s orientation relative to the pin's axis. In some cases this will result 
in a wasted alignment motion; in the worst case, the specified frame may not be 
reachable because of physical limits on joint travel of Liu: robot. Another use of 
partially specified object positions occurs in the interpretation of sensory data. 
When the robot makes contact with an, object, it acquires a constraint on the 
position of that objecL. This information does not uniquely specify the object’s 
position, but several such measurements can be used to update the robot's estimate 
of the object’s positions. This type of computation requires representing partially 
constrained pasolionH or, equivalently, constraints on the position parameters [Taylor 
7f>, Brooks 81]. 

Despite these drawbacks, coordinate frames are likely to continue being 
the primary representation oF positions in robot programs. Therefore, a robot 
programming system should support the representation of coordinate frames and 
computations on Frames via transforms, But this is not all- a world model also should 
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figure 4. Symbolic spccilicaLiuq of pasiti-uus 



points, ara not represented at ail, and must still be specified, Therefore, the effective 
use of CAD databases requires a high-level interface For specifying the desired 
positions. Pointing on a p-aphics screen is one possibility, but it suffers from the 
two-dimensional restrictions of graphics [Ambler, Popplesl.nne, and Kcmpr 82{. 
Another method [Ambler and Poppies tone 7S, Poppiestone, Ambler, and Bellos KOj 
is to describe position e Say sets of symbolic spatial, relationships that hold between 
objects in each position, for example, the positions of JJfocJcl in Figure 4 must 
satisfy tlm following relationships: 

(/S Ag'd^Tiist /l) and (/ 4 AgmtTisi /2) 

One advantage of using symbolic spatial relationships is that the positions they 
denote are not limited to the accuracy of a light*pen or of a robot, but that of 
the model- Aonth-er advantage of this method is that families of positions such as 
those on a surface or along an edge can be expressed. Furthermore, people easily 
understand Lhcsc relationships. One small drawback of symbolic relations is that 
the specifications are less concise than specifications nf coordinate frames. 

Another potentialEy important method of acquiring positions is the use of 
vision. For example, two cameras can simultaneously track a point of light from a 
laser pointer and the system can compute the position of the point by trianguSation 
[Ilasegawa S2j. One disadvantage of this method and of methods based cm CAD 
models is that there is no guarantee that the specified point can be reached without 
collisions- 

We have focused on the representation of single positions; this reIIeels the 
emphasis in current robot, systems on end point specification of motions. In many 
applications, this emphasis is misplaced, For example, in arc-welding, grinding, 
glue application, and many other applications, the robot is called upon to follow 
a complex path- Currently these paths arc specified as a sequence of positions. 
The next section discusses alternative methods of describing motions which require 
representing surfaces and volumes. A large repertoire of representational and 
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toiTLpLitationa] tools is already aval lable. in CAD systems and Numerically Controlled 
(NC) machining systems, e.g. ;1 [Faux and Pratt T9j. 

In summary, the data manipulated by robot programs is primarily geometric. 
Therefore, robot programming systems have a requirement to provide suitable 
data input, data representation, and computational capabilities for geometric data. 
QF these three, data input is the most amenable to solutions that exploit the 
capabilities of robot systems, e,g- r Che availability of the robot and its sensors. 

3,3. Motion specification 

The most obvious aspect of robot programming is motion specification. The 
solution appears similarly obvious: guiding- But, guiding is sufficient only when 
all the desired positions and motions arc known at programming time- We have 
postponed a discuss-inn of motion specification until after a discussion of sensing 
A~.fi :r:i>:li.'li:ig :o ei:: ;jliasi2t the LcufJiT :uigc o: > ■■:.■:! iti u i: Milder widen robot 
motion must be specified in sensor based applications. 

Heretofore, we have assumed that a robot motion is specified by its final 
position, be it in absolute coordinates or relative to some object. In many cases, 
this IS not sufficient; a path for Lhe robot must also be specified. A simple example 
of this requirement arises when grasping parts: the robot cannot approach the 
grasp point from arbitrary directions; it must typically approach from above dr risk 
colliding with the part. Similarly, when bringing the part to add to a sub-assembly, 
the approach path must be carefully specified. Paths arc commonly specified by 
indicating a sequence of intermediate positions, known as um. points, thaL the robot 
should traverse between the initial and final positions. 

The shape of the path between via points is chosen from among some basic 
repertoire of path shapes implemented by the robot control system. Three types of 
paths arc implemented in current systems: uncoordinated joint motions, straight 
lines in the joint coordinate space, and straight lines in cartesian space. Each 
of these represents a different tradeoff between spend of execution and '‘natural" 
behavior. They are cacti suitable to some applications mure than others. Robot 
ay sterna should support a wide repertoire of such motion regimes. 

One important issue in motion specification arises due to the non-uniqueness 
□f the mapping from cartesian to joint coordinates. The system must provide, 
some well-defined mechanism Tor choosing among the alternative solution®. In some 
cases, the user needs to identify which solution is called for. YAL provides a set 
of eon figuration commands that allow the user to choose one of the up to eight 
joint solutions available at some carte si an posi Lions. This mechanism is useful, 
but limited. Jn particular, it cannot be extended to redundant robots with infinite 
families of solutions or to specify the behavior ai a kinematic singularity. 

Some applications, such as arc-welding or spray-painting, can require very 
fine control of the robot’s speed along a path, as well as of the sfictpe of the 
path [Brady S3, Pan] -8!]- This type or speedFication is supported hy providing 
explicit trajectory control com mauds in the programming system. One simple set 
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of commauds could specify speed ami acceleration hounds on tiie trajectory. Al. 
provides for mid i Lion al specifications such as the total Lime of the trajectory - Given 
a wide range of constraints, it is very likely that ihe set of constraints for particular 
trajectories will be inconsistent. The programming system should either provide a 
well-defined semantics for treating inconsistent constraints 5 or make it impossible to 
specify inconsistent constraints. Trajectory constraints also should be applicable to 
trajectories whose path is not known at programming time, for example, compliant 
motions. 

The choice of via points for a task depends on the geometry of the parts, the 
geometry of the roboL, the shape of the paLhs the robot follows between positions, 
and the placement of the motion in the robot workspace, When the environment is 
not known completely at programming time, the via points must be specified very 
conservatively, This can result in unnecessarily long motions. 

A i l addi LLonal draw back of meti ons specs fled by sequences of robot confi gn r ati on s 
is that the via paints are chosen, typically, without regards for the dynamics of the 
robot as it moves along the path.. If the robot is to go through the via points very 
accurately, the. resulting motion may have to he very slow. This is unfortunate, 
since it is unlikely that the programmer meant the via points eactcfiy. Some robot 
systems assume that via points are not meant exactly unless told otherwise. The 
system then splines the motion between path segments to achieve a fast, smooth 
motion, hut one that docs not pass through the via paints |Pall] 81 j.. The trouble 
is that the path is then essentially unconstrained near the via points; furthermore, 
the actual p&Lh followed depends or, Lhc speed of the rooLion. 

A possible remedy for both of these problem is to specify the motion by 
a set of constraints between features of the lobot and features of objects hi the 
environment- The execution system can then choose Lhe ''best" motion that satifsifies 
these constraints, or signal an error Jf no motion Is possible. This general capability 
is beyond the state of the art in trajectory planning, but a simple form has been 
implemented. The user specifies a nominal cartesian path for the robot plus some 
allowed deviation from the path; the trajectory planner then plans a joint space 
trajectory that-satisfies the constraints [Taylor 79], * 

Another drawback of traditional motion specification is the awkwardness 
of specifying complex paths accurately as sequences of positions, More compact, 
description of the desired path usually exist. An approach followed in N r C machining 
is to describe the curve as the intersection of two mathematical surfaces- A recent 
robot language, MCL |McDonnell Douglas &DJ r has been defined as an extension to 
APT, the standard NC language. The goal of MOL is Ld capitalize on the geometric 
databases and. computational tools developed within existing AFT ays Leins for 
specifying robot motions. This approach ts particularly attractive for domains, such 
as aircraft manufacture, in which many of the parts arc numerically machined. 

r, A a[M:c:a] caie occur* when ihc computed path ewi through a kinematic singulartty. Ii in 
imposslblE iri general to satisfy trajectory constraints such as speed oJ the cad-cite to* at Uic 
singularity, 
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Another very general approach to trajectory speciflcatjon is via utscr-supplicd 
procedures paramctrrLxed by time. Paul '77. Sl| refers to this as /fmcfipfiaiiy 
dcjlttcd moiio rt The programming system executes the function to obtain position 
goals. This method nan be used, for example,, to follow a surface obtained from 
CAD data, turn a crank, and throw objects. The limiting factor in this approach 
is the speed at which the function can be evaluated; in existing robot systems f no 
method exists for executing user procedures at servo rates. 

A special caae of functionally defined motion is motion specified a* a function 
of sensor values. One example is in compliant motion specifications, where some 
degi-Ecs of freedom are controlled to satisfy force conditions. Another example is a 
motion defined re I alive to a moving conveyor belt. Both of these cases bte common 
enough that special purpose mechanisms have been provjded in programming 
system6. There are significant advantages Lu having these mechanisms implemented 
using a common basic mechanism. 

In summary, the view of motion specification as simply specifying a sequence 
of positions or robot configurations is too limiting. Me chartisms for geometric 
specification of curves and functionally defined motion ghould also be provided. No 
existing systems provide these mechazusms with any generality, however. 

3.4, Flow of control 

In the absence of any form oT sensing, a fixed sequence of operations is the only 
possible type of robot program. This model is not powerful enough to encompass 
Reusing, however. In general, t.he program for a Gcii^or-baaed robot must choose 
among alternative action h on the bads of its internal model of the task and the 
data From its sensors. The task of section 2 y for example, may go- through a very 
complex sequence of elates, because Lhc parts are arriving in random order acid 
because the execution of the various phases of the operation is overlapped. In each 
state, the task program most speciFy the appropriate action For each robot. The 
programming system must provide capabilities for making these control decisions. 

The major sources of information on which control decisions can be based are: 
sensors, control signals, and the world model. The simplest use of this information 
is to include a test at fixed places in the program in decide which action should 
be taken next, e.g,, If (i < j) then Signal X else Move to T. One important 
application where this type of control is suitable is error detection and correction. 

Robot operations are subject to large uncertainties in the initial state of the 
world and in the cITiiel of the actions. As a result, the bulk of robot programming is 
devoted to error detection and correction, Much of this testing consists of comparing 
the actual result or an operation with the expected results. One cduiitldii exam pic 
is testing the linger ripening after a grasp operation differs from the expected value, 
indicating either that the part is missing or a different part is there. This typo of 
test can be easily handled with traditional H< , -TNiSN tests after completion of Lite 
operation. This test is so common that robot languages such as YAL and fAVfc [Paul. 
7T| have made it part of the semantics oF the grasp to mm and- 
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Many mbot applications also have other requirements that do not fall naturally 
within the scope of the IF-THEN conLml structure. Robot programs often must 
interact with people oi machines, nidi an feeders, belts, NC machines, and other 
rnhrjts. These external processes are Executing in parallel and asynchronously; 
therefore, it is not possible to predict exactly when events of interest to the robot 
program may occur, in the task of See Lion 2, for example, the arrival of a part 
within the field of view of one or the cameras calls for immediate action; cither 
one [jf the robots must be interrupted so as to acquire the part, oi the belt must 
he stopped until a robot can be interrupted. The previous operations may then be 
resumed. Other examples occur in detecting collisions or part slippage from, the 
fingers; monitor processes can be created to continuously monitor sensors, but they 
must be able interrupt the controlling process and issue robot commands without 
endangering ongoing tasks, 


It is possible to use the signal lines supported by mosL robot systems to 
courdinate multiple robots and machines. For example, in the sample ta&kj the 
insertion of the pins into the pump cover (steps b through S In Section 2) requires 
that ROBOT 1 and ROBOTS be coordinated so as to rmnimitc the duration of the 
operation while avoiding interference among lire robots. If we lei Robotl be in 
charge, we can coordinate the operation using the following signal lines; 


1. GET-PLN?: ROBOTS asks if it is safe to got a new pin. 


2 . QK-TQ-GET; ROBOT 1 says it is OK, 


3. INSERT?: ROBOT 2 asks if it is safe to proceed to insert the pin, 


4, OK-TO-INSERT: ROBOTL says it is OK, 


5. DONE; R0BQT1 says it is all over. 


The basic operation of Lhe control programs canid be ns follows: 
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ROBOTl 

Va.it lor CDYEil-ARRIVED 
Signal OK-TO-CET 
5 := 1 

C*n Pla.ce-Ccvcr-lEi-riJtt.ure- 
J: fait for INSERT-PIN? 

Signal Qt-TO-INSERT 
if (1 * up) do 

[Call Cet-FSji-l 
1 l= i*lj 
else da 

[Signal DONE 
Cat* 2] 

Halt for CET-FJlf? 
if (1 < up) then do 
[Signal cm-TO-GET 
i ;- i-*ll 
Call insert-Pin-1 
Cot,* I 


I i.Jilml III ill: lift 


iLUHDTS 

3; I(signal WNE Cote 4 
Signal GET-EiJf? 

Wait for OK-TO-SET 
Call Get-Pin -2 
Signal INSERT-PM? 
Wait, far OK TO ’ INSERT 
Call Insert-Pin-£ 

■Soto 3 
4: rr - 


Tliifi illustration of how a simple coordination task could be done with only binary 
signals also serves to illustrate the limitations of the method, 

1. The prog.rams are asymmetric, one robot is the master of the operation, 
if the cover can arrive on either belt arid be retrieved by either robot, 
then either an additional signal line is needed le indicate which robot 
will be the master or both robot systems must be subordinated to a third 
ccmtrolier- 

2. If one of the robots finds a defective pin, there is no way Tor it to cause 
the oLher robot to insert an additional pin while it goes to dispose of the 
defective one. The program must allocate new signal lines for this purpose. 

In general, a large number of signals may be needed. 

2. Because one robot docs not know the position nT the other one, it is 
necessary Lo coordinate them on the basis or very conservative criteria, 
e.g., being engaged in getting a pin or inserting a pin. This will result 
in slow execution unless the tasks are subdivided very finely aud tests 
performed at each division, which is cumbersome. 

■1. The position of the pump cover and Lhe pin-feeder must be known by each 
process independently. No information obtained during the execution of 
the task by one robot can be used by the other robot; it must discover 
the information independently. 

The difllcuFtie.s outlined above are the due to limited communication between the 
processes. Signal lines are a simple, but limited, method of transferring information 
among the processes. !n practice, sophisticated tasks require efficient means for 
coordination and for sharing the world model (including the state of the robots) 
between processes. 
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The issue of coordination between cooperating and competing asynchronous 
processes is one of the most active research areas in Computer Science. Many 
language mechanisms have been proposed for process synchronisation, among Lhnse 
arc’ semaphores Dijkstra t!S|j events, conditional critical regions (Huare I972|, 
monitors and queues [Brinch Hansen 75], and comunieating sequential processes 
[Eloare 7#|. Robot systems should build upon these developments, perhaps by 
using a language such as Concurrent Pascal [Brinch Hansen 75| or Ada jtchbiah 
JO] as s base language- A few ex in Ling rubot jangusges have adopted some of 
these mechanisms, c.g., Ab and TEACH [RuofT 79, SiOj. Even the most sophisticated 
developments in computer languages do not address all the robot coordination 
problems, however. 

When the interaction among robots is subject to critical reahtime constraints, 
the paradigm or nearly independent control with periodic synchronization is 
inadequate. An example occurs when multiple robots must cooperate physically, 
e.fc, in lifting an object top heavy for any one. Slight deviations from a pre-planned 
position trajectory would, cause one of the robots to bear all the weight, leading to 
disaster, What is needed, instead, is cooperative control of both robots based on 
the force being exerted on both robots by the load [Ishid* 77, Maaon 81, Nakano 
et al. T4|. The programming system should provide a mechanism for specifying the 
behavior of systems more complex IL^jl a single robot. Another example of the need 
of this kind of coordination ls in the programming and control oT multi-fingered 
grippers [Salisbury arid Craig 82], 

In summary, existing robot programming systems are based on the view of a 
robot system as a single robot weakly kinked to other machines. In practice, many 
machines including sensors, special grippers, feeders, conveyors, and several robots 
tsiay be cooperating during a task. Furthermore, the intrracLions between them may 
be highly dynamic, c.g. r to maintain a iWcc between them, or may require extensive 
sharing of information. No existing robot programming system adequately deals 
with all of these interactions, in fact, no existing computer language is adequate 
to deal with this kind of parallelism and real-time constraints, 

3.5. Programming support 

Robot applications do not occur m a vacuum. Robot programs often must access 
externa] manufacturing data, ask users Tor data or corrective action, and produce 
statistical reports. These functions ate typical of most computer applications 
and are supported by all computer programming systems. Many robot systems 
neglect to support them, however. In principle, the exercise of these functions can 
be separated from the sqj-ccification of the task itself but, in practice, they are 
intimately intertwined. A sophisticated robot programming system must first be a 
sophisticated programming system. Again, this requirement can be readily achieved 
by embedding the robot programming- system within an existing programming 
system. Alternatively, care must be taken in the design of new robot programming 
systems not to overlook the ""mundane” programming functions. 






A similar situation exists with respect to program development. Robot prop-am 
development is often ignored in the design of robot systems and, consequently, 
complex robot programs can be very difficult to debugs. The development of robot 
programs has several nharacteri&tics which merit special treatment; 

1. Robot programs have complex side-elTects and their execution time is 
usuaily long, hence It is nuL always feasible to reinitialise the program 
upon failure. Robot programming systems should allow programs t* be 
modified on-line and immediately re-started. 

2 . Sensory information and real-time interactions are not usually repeatable. 

(hir useful debusing Lou-1 for sensor-based programs provides the ahilily 
la record the sensor outputs, together with program traces. 

3. Complex geometry and motions are difficult ixi visualise; simulators can 
play an important role in debugging, fur example, see (Hegimbotham. 
Dooner, and Case Til. Soroka 80, Meyer Si], 

These are not minor considerations, they are central to increased usefulness of 
robot programming systems. 

Most existing robot systems are stand-alone, meant to be used directly by a 
single user without the mediation of (minputers. This design made perfect sense 
when robots were not controlled by general-purpose computers; today it makes 
little sense. A robot system should support a high-speed command interface tu other 
computers. Therefore, if a user wants to develop an alternate interface, he need not 
be limited by the performance of the robot system’s user interface. Qn the other 
hand, Lhe user can take advantage of the ccmLrol system and kinematics calculations 
in the existing system, This design would also facilitate the coord iTration of multiple 
robots and make sophisticated applications easier to develop, 


4. Survey of Robot Programming Systems 

In this section, we survey several existing and proposed robot programming 
systems, 

4.1. Guiding 

AH robot programming systems support some form of guiding. The simplest 
form of guiding is to record a sequence of robot, positions that can then be ''played 
hack'"; we call this basic /jmdnig. In robot-level systems, guiding is used to define 
positions while the sequencing is specified in a program, 

The differences among basic guiding systems are (a) in the way the positions 
are specified and (b) the repertoire of motions between positions, The most common 
ways of specifying positions are: by specifying incremental motions on & teach 
pendant, and by moving the robot through the motions, either directly or via a 
mastcr-slave linkage. 
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The incremental motions specified via the teaeb-penda.nl can lx; interpreted 
as. independent motion of each joint between positions, straight lines in the joint- 
coord]]] ate space, or straight lines m cartesian space relative to some coordinate 
system, e. g, :l the robot's base or the robot’s end-dTeetor- When using the teach- 
pendant, only a few positions are usually recorded, on command from the instructor- 
The path of the robot is then interpolated between these positions using one of the 
three types of motion listed above. 

When moving the robot through the motions directly, the complete trajectory 
can be recorded as a series of closely spaced positions on a fixed time base. The 
latter method, is used primarily in spray-painting, where it is important to duplicate 
the input trajectory preciselv. 

Tbe primary advantage of guiding is its immediacy: what you sec is what 
you get. In many cases, however, it is extremely cumbersome, as when the same 
position {or a simple variation) must be repeated at different points in a task or 
when fine positioning is needed. Furthermore, wc have indicated repeatedly the 
importance of sensing in robotics and the limitations of guiding in the context 
of sensing. Another important- limitation of basic guiding is in expressing control 
structures, which inherently require beating and describing alternate sequences- 

4.1.1. Extended Guiding 

The limitations of basic guiding with respect to Sensing and controE can be 
abated, though not completely abolished, by extensions short of a full programming 
language, For example, one of the niosL common uses o’" sensors in robot- programs 
is to determine the location of some object to be manipulated. After the object 
is located, subsequent motions are made relative Lo the object's coordinate Frame - 
This capability can be accomodated within the guiding paradigm if taught motions 
tan be interpreted as relative to some coordinate frame that may be modified 
at execution time- These coord in a te frames can he determined, for example, by 
having the robot move until a touch sensor on the end-effector encounters an object. 
This is known as a guarded moUan or a search* This capability is part uf some 
commercial robot systems, e.g., ASEA [ASEA], Cinciuatti Milacron (Holt FT], and 
TTCM jCrossmaj'i 77, Summers and Clrossuian 82]. This approach could bn extended 
to the case when the coordinate frame? are obtained from a vision system. 

Some guiding systems also provide simple control structures. For example, the 
instructions m the taught sequence are given numbers. Then, on the Lias is of tests 
on external or internal binary signals, control can be transferred to different points 
in the taught sequence. The ASiiA and CincsnalLi Mi Lauren guiding systems, Tor 
example, both support conditional branching. These systems also support a simple 
form or procedures. The procedures can. be used to carry out common operations 
performed at different times in the taught sequence, such as euroumn machining 
operations applied to palletised parts. The programmer can exploit these facilities 
to produce more compact programs. These control structure capabilities are limited, 
however, primarily because guiding systems do not suport explicit computation. 
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Figure 5, Tallctismg Ta.sk 



To illustrate the capabilities of extended guiding systems, we present a simple 
task programmed in the A SEA robots guiding eysunA The task is aHusi-rated in 
Figure 5; at consists of picking a series of parts of different heights from a pallet, 
moving them, to a drilling machine, and placing them on a different pallet. The 
resulting program has the following structure; 


''Tliii pirjgmm is bijod on Lwt> pfugraai l\-^ iu-ui U included in the A Li LA manual jAt3iiA] 
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Instruction 

Rcn.ark.ii 

id 

OUTPUT OS 17 

Flag C$ jndicites do pickup 

£0 

PATTERN 

EiogLEiJiii.g of procedure 

JG 

TEST JUNE 17 

Slip next instruction if flag is on 

40 

JUMP 170 


ED 

OUTPUT OFF 17 

Nest tine do pvt down 

60 

V . . 

Pickup operation (see belov) 

100 

HOD 

Fni of cnmnbii code for pickup 

110 


Positioning for first pickup 

ISO 

HOD 

Ficcute procedure 

140 

. . . 

Positioning for s&coad pickup 

iso 

HOD 

Execute procedure 

170 


Uachlmng and put dean operation 

200 

OUTPUT ON 17 

Xeit tine do pickup 

210 

HOD 

End of oonnoji code for put dovn 

220 

• ■ r 

Position far first put doth 

230 

yi.ic 

Execute proc«iuro 

240 

- - - 

Position for second put do«n 


NoLc that the MOD operation is muid with two meanings; [1] to indicate the 
end of a common snr.Li »rt of the PATTERN, and [2] to indicate whore the 
com man set lion is to be executed. The sequence of instruc Lions cxcctcd would be: 
10, 20,30, 50, 60, „ , p 100,.,,, 130,30, 40, 170,. - -, 200,,.., 250,30,50,... 

The key to the pickup operation is that we can use a search to locate the top 
suiFace eT the part, ko wc Ticcd not know the heights exactly. The pickup sequence 
could be programmed as follows [fingers are assumed dosed initially). 


Programmer action. 


Renark b 


1. POHititm robot t<? FU r P2 la ob top the shortest part. 

2. PCEltlOJ! Vertically W Pt ■ PI i= above the highest jjatt, this motion, 

insures that. Pi is directly ;ibavr P2 . 

3. Select speed for notion 
to FI. 


4. PTPf 

E. Position vertically to P2. 
6. Select spu-nd ^ p 3. 

T. Key code for search and 
vortical operation. 


Point- to-peg nt mat job with fins position 
control at the end of the notion 
This marks the end oi the search 

This code indicates that the motion that 
foilons is a search ib vertical direction. 


e. FTPF 

9. SeL grip opening and 
select waiting tine . 

1(5 ■ GRIPPERS 

11. Position to P3. 

12. Select time for notion,. 


Floe positioning 
Specify finger cpciiicg 

Insert comtand to actuate grippers. 
Grasping position, {relative to P2) . 
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id. Set-grip opening and 


13. PTFL 


Ctsijrdin&ted joint notion, relative- to the 
poilHiin aftcf l3iu search.. 

Specify fingnr closing 


sal nrt, suiting tin* 

IS. CfllfPEPS 


rOmiLuid to LiCt-uaVt grippairr. 


The putdown sequence would be programmed in a similar fashion, 

4.1.2. Off-line guiding 

Traditions.] guiding requires that the workspace fevr the utsk, alt the tooling, 



single large or expensive part, such as an airplane, ship, or automobile, it may 
be impractical to wait until a completed part is available before starting the 
programming; this could delay tbe complete manufacturing process. Alternatively,, 
the task environment may be in space or underwater. In these cases, a tnockup of 
the task may be built, but a more attractive alternative is available when a CAD 
model of the task exists. In this case, the task model together with a robot model, 
can be used to define Die program by off-line r/iiTt/uij. In this method, the system 
simulales the motions of Lhc robot in response to a program or to guiding input 
frnrn a Leach pendant. Off line guiding offers 1-hc additional advantages of safety and. 
versatility. In particular, it is possible to experiment with different arrangements 
of the robot relative to the task so as to find one that. Tor ex ampin, mimmives task 
execution time [Htginbotham, Doancr, and Case 7fl] 

4.2. HolmUlevc] programming 

Tn section. 3 we discussed a number of important functional issues in the design 
of robot programming systems. The design oT rebel-Level languages, by virtue 
of its heritage in the design of computer languages, lias inherited many of the 
controversies of that notoriously controversial fmld. A few nr these controversial 
issues are important in robot programming: 

J. Compiler os, tfiterprcfeT-. Language systems that compile high-level 
languages into a lower-level language can achieve great efficiency of 
execution as well as early detection of some classes of programming 
errors. Interpreters, on the other hand, provide enhanced interactive 
environments, including debugging, and arc more readily extensible. 
These human factors issues have tended to dominate; most robot language 
systems are interpreter based. Performance limitations of interpreters 
have sometimes interfered with achieving some useful capabilities, such as 
Functionally defined motions. 

2. Ncurus. oM. Is it better to designs a new language or extend an old one? 

A new one can be tailored to the need of the new domain. An old one 
is likely to be more complete, to have an established user group, and to 
have supporting software packages. In practice, few designers can avoir! 

LEie temptation of starting de noft?; therefore most robot languages are 
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"new 11 languages There are, in addition, dslflunities in acquiring sources 
for existing language systems. One advantage of interpreters in this regard 
is that they are smaller programs than compilers and, therefore, easier to 
build. 

In the remainder of the section, we examine some representative robot-level 
programming systems, in roughly chronological order. The Languages have been 
chosen to span a wide range of approaches to robot-level programming, We use 
examples to illustrate the “style 11 of the languages; a detailed review of all these 
languages is beyond the scope of this paper. We ciose the section with a brief 
mention of some of the many other robot-level programming systems that have 
been developed in the past ten years. 

1,2.1. MKI I&G0-19G1 

The first robot-level programming language, MH1, was developed for one of 
the earliest computer-controlled robots, the MH-1 at WIT ; Ernst 6l|. As opposed 
to its contemporary the Unimate, which was not controlled by a general-pur pose 
computer and used no external sensors, MIT-1 was equipped with several binary 
touch sensors throughout its hand, an array of pressure sensors between the 
fingers, and phnto-dmdes on the bottom of the fingers. The availability of sensors 
fundamentaly affected the mode of programming developed for the MH-i, 

ME I (Mechanical Hand Interpreter] ran on an interpreter implemented on 
the TX-U computer. The programming style in UKI was framed primarily around 
guarded moves, i.e,, moving until a sensory condition was detected- The language 
primitives were: 

1. jmive: indicates a direction and a speed. 

2. until: test a sensor For some specified condition. 

3. ifgoto: branch to a program label if some condition is detected. 

4. if continue ; branch to continue action if same condition holds, 

A sample program, taken from [Ern&t 61], follows: 


a, znnve x far 12Q 

until si ID rfll lei 

■until ft 206 lol ih? stp 

ifgntp ft.to 
ifgoto 6 f2 
Ifcontinue to,* 


; Move »lcr.g x ti tb speed 120 
; until sense organ l 
; indicates a decrease or :C, relative 

J td the Value iL start, n t thin st.cp 
; CcOBdj tion ll 

; or until sense organ 1 indicates 
; 20£ or 1«sp ibielufte, tben atop. 

; Condition, 2] 

; if condition 1 alone Is fulfilled 

; g.u to iequBUtL' to 

r il It least condition 2 Is fulfilled 
; go to sequence c 

r in all other esses continue sequence a 


LcitMf.-n- Pixul 
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MHI did not support arithmetic or any other control structure beyond sensor 
monitoring. The language, atill, is surprisingly ‘'modern" and powerful It was to 
bo many yeart before ft more general language was implernented- 

1.2.2. WAVE 197U 1075 

The HAVE jPauil 77] system., developed at Stanford, was the earliest system 
designed as a genera I -purpose robot programming language. HAVE was a “new* 
Language, whose syntax was modeled after the assembly Language oi the PDP-10. 
WAVE ran off-line as an assembler on a PDP-IU and produced a trajectory file 
which was executed on-line by a dedicated PDP-6. The philosophy in WAVE was 
that motions could be pre-planned and that only smalt deviations from these 
motions would happen during execution. This decision was motivated by the 
computation-in tensive: algorithms employed by WAVE for trajectory planning and 
dynamic compensation, llelter algorithms and faster computers have removed this 
rationale from the design oF robot systems today. 

In spile of wave's low level syntax, the system provided an extensive repertoire 
of high-level functions. WAVE pioneered several iruportajit mechanisms in robot 
programming systems; among these were; 

1. The description of positions by the cartesian coordinates of the end-effector 
(it,y,a, and three Euler angles]. 

2. The coordination of joint motions to achieve continuity in velocities and 
accelerations, 

3. The specification of compliance in cartesian coordinates, 

Thfl followinjt program ijj WAVE, from [Paul 771, serves to pick up a pin and insert 
it into a hole: 


TRAMS FIX .„. 
TRANS HOLE . . 


Location of pin 
Location of hold 


AGCTCH TRIES 2 


Number pf pickup attempt? 


MOVE PIN 


Hove to PIN HOVE first moves in +Z 


then to a point above PIN. then -Z. 


PICKUP: 


CLOSE i 
SKIPE 2 


Pickup pip 

Skip nertt instruction if Error 2 occurs 
(Error 2: fingers closed beyond arg to CLOSE) 
Error did not occur, gutu UK 
Error did occur, opcti the fingers 

Hove do»t one inch 

Decrement TRIES, if not negative 

jump to FICXUF 

Print H JJ0 PIM H and salt for operator 
Tty a^iin *3icn Operator Lypet; PROCEED 


JUMP OK l 

anr.N & ; 

CHANCE 7,-1,NIL,0,0 i 

SQJG TRIES,PICKVP j 


IAIT NO PIN 
JLTUP PICKUP 


Lud iL'-l'trtj 


I'n^r-iiiaii' lid, 


OK: 

udve :iq:.e 
STOP Pi',NIL 
CHANGE 2,-l.NIL.Q.O 
SKIPE 23 
JUMP XUHULE 
FREE l.X.Y 

SPIN £,3f,Y 
STOP FV.NIL 
CelANGE Z ,-2,.NIL.O , 0 
PGHPLE: 

HAIT NO HOLE 


Habcvc hale 
Stop ors SO gz ■ 

Try to go dean one IdcJi 

Error 23, filled to stop 

Error did iiot ooiiir (pin bit sorfaofr) 

Proceed Tit-li insertiwi by complying 

•itb forces along £ and y 

AJec comply with tor^aep about, % and y 

Stop on SO 02 . 

Hake the iii-strtioc, 

Filled 


Mote t"h f> ii ec of comp] j ante acid guarded moves to achieve robustness in the presence 
of uncertainty and for error recovery, 

IA'AVE : s syntax was diJfLcuJl, but the language supported a signi ficant set of 
robot functions, many of which still are not available in commeicial robot systems. 

0 . 3 . MINI 1912-1976 

MINI ‘Silver 73J, developed at M1T> was not a °new" language rather it was an 
extension to an existing LISP system by means of a few functions. The functions 
served as an interface to areal-time process running on a separate machine, LISP has 
little syntax; it, is a large collection of procedures with common calling conventions, 
with no distinction between user and system code. The robot control functions of 
MINI simply expanded the repertoire of functions available to the LISP programmer. 
Users could expand the basic syntax and semantics of the basic robot interface at 
will, subject to the limitations of the control system. The principal limitation of 
MINI was the fact that the robot joints were controlled independently. The robot 
used v?ith MINI was cartesian, which minimised the drawbacks of uncoordinated 
poilit-to-point motions. 

The principal attraction of "The Little Robot System" [Silver 73j Inoue 
PI| in which MINI ran was the availability of a hi-gb-quality 6-dcgroe-of-fracdojn 
force-sensing wrist |Tnone 7d p Minsky 72J which enabled sensitive force control of 
the robot. Previous force-control systems either set Lhc gains in the servos to control 
compliance [Innue 7l|, or used the error signals In the servos of the electric joint 
motors to estimate the forces at Lhc hand [Paul T2}. In cither case, the resulting 
force sensitivity was on the order of pounds; mini's sensitivity was more than an 
order or magnitude bcLLer (approx. 1 02-). 

The basic functions in MINI set petition or force goals for each of the degrees of 
freedom (SETM), reading the position and force sensors (getm), and waiting for some 
erudition to occur (MATT)- ^Ve wilt illustrate the use of MINI using a set of simple 
procedures developed by I no lbs [Td]. The central piece of a peg-in-hole program 
would be rendered as follows in MINI: 


Loit.u'u-E'iru 


Il'L'LilL SUttgriinijiLrig 


(DtFLfN HCYE- AED'/E (JP OFFSET) 

; St L X,f t Z gnal= and 

{X- (X-LDCATIQN p)) 
<y= CT-LOCATIPIf F ]0 
(Z- (PLUS {Z-LOCATTO!! 
(WAII ’(AND {m {1ft 


nail till thty *rs r9«h«id 

F> OFFSET)? 

(TZ)») 


(DEFUN INSERT (HOLE) 

(MCVE-AHOVE HOLE 0,25) 

; define a target 1 itch Lelow current position 
(££fQ ZTARGET (DIFFERENCE (GETM ZPOS) 1.0>) 

- move down until a cottict lorct is net or until 
; the position target is mat. 

(FZ= LANDING -FORCE) 

(BAIT '(OH (?FZ) (SE0 (GETH ZPOS) ZTARGET?>> 

(COND ((SEQ (CFTU IFD5) ZTARGET) 

: if the posriticji fjoal was rrat.. i. e. to surfatE encountered 
; comply with lateral rupees 
(FX= U) (FT= Q) . 

; and push corn until enough resistance is met- 
(FZ= INSERTION-FORCE) 

(WAIT ’(FZ>)> 

[T ; if ? surfact *ac encountered 
(EflftOR INSERT)») 


MINI did not have any of the geometric and control ope rations of HAVE built 
in,, but most of these could easily be implemented as LISP procedures. The 
primary functional difference between the two systems lay in the more sophisticated 
trajectory planning facilities of WAVE. The compensating advantage of MINI was 
that iL did not require any pre-planning; the programs could use arbitrary LISP 
computations to decide on motions in response to sensory input, 

4 . 2 . 4 . AL md-presertt 

AL jFinkel, et at. 71, Mujlaba and Goldman 79] is an ambitious attempt to 
develop a high-level language that provides all the capabilities required for robot 
programming as well as the programming features of modern high-level languages, 
such as ALGOL and PASCAL. AL was designed to support robot-level and task-level 
specification. The robot level has been completed and will be discussed here; the 
Lask level development will be discussed in section 4.3. 

At, like HAVE and MINI, runs on two machines. One machine is responsible fn-r 
compiling the AL input into a Lower-level language that is interpreted by a real-time 
control machine- An interpreter for the AL language has been completed, as well 
[SSiu ford 79], AL was; designed to provide four major kinds of capabililies" 

1, Tbc manipulation capabilities provided by the WAVE system: cartesian 
specification of motions, trajectory planning, and compliance. 


LiIiuiIL-lh b 1 «i left 
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2 . The c liabilities of a. real time language; concurrent execution of processes, 
synchronisation t and on-conditions, 

3. The data and control structures of an ALGOL-) ita language, including data 
types for geometric calculations, e.g., vectors, rotations, and coordinate 
frames. 

4. Support for world [Modeling, especially tlie AFF1XMENT mechanism lor 
modeling attachments between frames including temporary ones such aa 
formed by grasping, 

An AL program for the peg-in-hole task: is: 

717.GIN "insert peg into hole" 

FTLAUE peg_ bottoir, ..grasp, lids_tvttvn. tola_tap: 

{ The eooffl mates Iranes represent Actual positions ol object JniAfcuros. 
not hind past Lions ]■ 

png_b::Mo.Ti * FRAME(nllrot,VECTOR<20,30,0) *inehee'l e 

h.ole_botton * FRAME, [hi.] Cbt .VECTQ3t(25,36,0>^iDehes) ! 

{ Grasping position relative- to peg_Lotboai } 

peg. grasp - FB ANE(ROT{?)i »t. t8-0*d«grn■ O , a*shat*in-ckna)i 
trios- * 2; 
grasped + FALSE; 

{ The top oT the hole ic defined to have a Iute-J relation to the bottom } 
AFFIX hole._top to hoie—bcttpin RTCICH-Y 
AT TRAMS (nilrot ,.3*zh*t*iiie , heB); 

OPEN hhand TO peg_diarte ter + 1*inches: 

i| Initiate fhn motior to the pag, noLc the destination Ij sJrie } 

MOVE barn TO peg_botbon * peg_grasp; 

WHILE- NOT grasped ANP i c tries CO 
BEGIN * Atterr.pt grasp* 

CLOSE bhand TO 0 « Inches,: 

IF bhaad < peg.d L imeter/2 

THEN flEGlK "No -object la grasp* 

OPE3i bhand TC peg^dianeter + 1 * Loehes; 

unvr. barn. TO -0i - 1 * inches; { @ ln-lii a tea ill r rent local ion 
END- 

LLSE grasped ■<- tRUE: 

EKO 

IF NOT grasped THFAI ABDRTf-Failad to grasp the peg"): 

\ Establish a fnca relation between arm and peg ]- 

AFFIX peg_bottom TO barn EllGlDLY: 

| Hct.o that ve save the pe-p,_hot Lon, r,Dt. barrr, j 

MOVE png_bottem TO hole_tap; 

■{ Test if a bole Is belo-w us } 

MOVE barn TD - i * Inches 

ON FORCEfrhit) ? Ifl- • amices DO ABORTt'No Hoi**); 


Luju.i'l-u- I'irex 


J-L-uboL- J'rL'KEa.iiiiiinK 


{ Exert ;3o*Tnrar«L lores. ?di 1 1 e complyir.g UP side forces } 

MOVE _bottom to hole_bottoit DIHECILT 

KITH FORCE_TRANE = station IN WORLD 

WITH FOKE(zhat) - -10 * ounces 
WITH FORCE (mut) = 0 « ounces 
WITH FORCE(r!iit) = D • *iinces 
SLOMLYj 

END '■insert peg JP- bole" 

AL in probably the most complete robot programming system yet developed; it was 
the first robot language to be a sophisticated computer language as well as a robot 
control language. AL has been a significant influence on most later robot langrtages- 

4.2.5. VAL 1975 present 

YaL StLimano 79, Unimation tiO] is the robot language used in the industrial 
robots of Unimation Inc., especially the PUMA series. It was designed to provide 
a subset of the capabilities of wave oh a stand-alone mini-computer. VAL is an 
interpreter; improved trajectory calculation methods have enabled it to forego any 
off-line trajectory calculation phase. This has improved the ease of interaction with 
the language. The basic capabilities of the VAL language are: 

1. Point-to-point, joinL interpolated, and cartesian motions [including ap- 
proach and deproarja motions]; 

2, Specification and manipulation of cartesian coordinate Frames, including 
the specification of locations relative to arbitrary Frames; 

3. Integer variables and arithmetic, conditional branching, and procedures; 

4, Setting and testing binary signal lines and the ability to monitor these 
litics and execute a procedure when an event is detected. 

VAL'e support of sensing is limited to binary signal linos. These lines can be 
used for synchro nidation and atso for limited sensory interaction as shown earlier. 
VAL’k support of on-line frame computation is limited to composition of constant 
coordinate frames and Fixed translation offsets on existing Frames. It does support 
relative motion; this, together with the ability lo halt a motion in response to a 
signal, provides the mechanisms needed Tor guarded moves. The basic VAL also has 
heen Extended to interact with hu industrial vision system [Gleason and Agin 79] 
by act;airing the coordinate frame of a part in the field of view. 

As a computer language, VAL is rudimentary; it most resembles the computer 
language BASIC- VAL only supports integer variables, noL Floating point numbers or 
character strings. VAL does not support arithmetic on position data. VAL does not 
support any kind of data aggregate such as arrays or lists and, Although it supports 
procedures, they may not take any argument*, 

A sample VAL program for the peg-in-hole task, is shown below. YAL does not 
support compliant motion, SO this operation, assumes either that the clearance 
between the peg and hole is greater than the robot's accuracy or that a pzrssive 
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compliance device is mounted on the robot's end'cdec-tor [Whitney S2j. This limits 
the com pari socle that can be made to other, more general, languages. In the 
example, we assume that a separate processor is monitoring a force sensor and 
com muni eating with YAL via signal lines. In particular, signal line 3 goes high if the 
2 component of force exceeds a pre-set threshold. 

set I tries ■= 2 


REMARK If tbs hand cls’Sfls: to last thiiia 100 hn r ges to sUteiMitt labelled £0 
10 GRASP IOC. id 

H£jy,HJI Othfl nr a n r caiitLuue nc. atateffieeli 30. 

GOTO 30 


2ti 


REUiUtK Open tbe fingers. displace dmrti along *or Id 2 . aits iod try again. 

OPEN I &D0 

DRAI 0,0.-200 

SET! TRIES = TRIES - 1 

IF TRIES G£ 0 THEN 10 

rrPE no pin 

STOP 


REMARK Uuve 30S.ni) above HOLE following a straight lino. 
iti APPR-DS HOLE. 3CO 

RENARK Idem t tar ritual line 3 and call procedure END IT Vo STOP the prsvgrwt 
REMARK if tbci si gnaT is activated durilig Uit nest IrjOtlsr. 

REACTI 3 r ENDIT 
APPROS HOLE, ICD 

RENARK Bid not fe-el force, so continue to ROLE. 

MOVES HOLE 


VAL has beer, designed primarily for operations involvicig pre-defmed robot positions, 
hence its limited support of computation, data structures, and sensing. A new 
version of the system, VAL -2, ia under development which incorporates more support 
for computation and cnmrtnmi cation with external processes. 

AML 1&77- present 

AYL. jTayhir, Summers, and Meyer fl2| is the robot language used ir. IBM's robot 
products. AML, like AL, is an attempt at developing a complete "new" programming 
language for robotics that is also a full-Hedged, computer language. The design 
philosophy oF AML is somewhat different from that of AL, however. Where AL focuses 
on providing a rich set of built-in high-level primitives Tor robot operations, AML has 
Focused on providing a systems environ merit who re different user robot programming 
interfaces may he built. For example, extended guiding (Summers and Grossman 
S2| and vision interfaces [Lavin and Licherman S'2\ can he programmed within the 
AML language itself. This approach is similar to that followed in MENI. 

AML supports operations on data aggregates, which can be used to implement- 
operations on vectors, rotations, and coordinate frames, although these data types 
arc net part- oT the language- AML also supports joint-space trajectory planning 
subject to position and velocity constraints, absolute and relative motions, and 
sensor momtonne that can interrunt motions. AML does not suooort cartesian 
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motion, com plight motion 7 . affiKmeftt of frames, or multiple procesSM. An AML 
progra-m for pcg-in-hole might be; 

PICKUP. SUBK (PAST_DATA , TKIES) ; 

MOVE(GRIPPER, DIAMETER (PART_DATA)+0.2); 

M0VE(<LS,3>, XYZ_ P0SITMlHPAHT_MTA)*^,6,a>); 

try _p ickup ( part_pat a . tries? f 

END; 

mV PICKUP: SIJURCPAftt .DATA, TRIES? ; 

IF TRIES LT t THEN aVTURHC'H0 PAST'?; 

DMOYEEa.-l.O); 

IF GRASP(DIAMETER(PART—DATA)) = 'HU PART h 

THEN TRY_PICKUP (FART MIA, TRIES ' D I 

END; 

GRASP: SUEft (DIAMETER, F); 

FM0N3: HEW APPLY(I MONITOR, FINCK..FORCE(F)): 
llOYEfCHIPPER r 0. fWNSh 

ElETUfUJ ( IF SP0EJT1DN (GRIPPER) LE DIaMETER/2 
THEN "KD FART' 

ELSE ‘PART' ): 

END; 

INSERT: SUBR(PART.. DATA, I»LE> ; 

FBJOHS ; NEW APPLY(.S HQh'lTOR, TT P—FCTSCE (LANDI NG_FORCE?) ; 

MDVEC<1,2,3>, HOLE+CO.Q.,25>?; 

D»0V£{3. -1.0, FMQN5>: 

IF (?M0 HJLTQfl: CfHOWS) - ] 

THEN RETURN("NO HOLE'); 

NQYE(.3 t HOLE(3) < FART_LENGTH (PART_DATA)? ? 

PHD; 

FART_Ilf—HOE-E: ES7HH (PART_DATA . HOLE? ; 

(FiCKUP PART-DATA 2.?; 

(INSERT PART-DATA HOLE? j 
END; 


This Example has shown the implementation of low-level routine* such as GRASP, 
that are available as primitives in AL and VAL, In general, such routines would 
be incorporated into a programming library available to users and would be 
in distinguishable from built-in routines, l'be important point is that such programs 
can be written in the language. 

The AML language design has adopted many decisions from, the designs of the 
LISP and APL programming languages- AML, like LISP, does not make distinctions 
between system and! user programs. Also AML provides a versatile uniform data 
aggregate, similar to LESP : h lists, whose storage is managed by the system. AML, 
like AFL and LISP, provides uniform facilities fur manipulating aggregates and for 
mapping operations over the aggregate!?. 

7 Cumpllhjil matlans at low-apcca wold be written, as user inograma in AML bj uihf Lu ihibot 
]/0 gp-trutjrjQB. Foi Inprit-spiM.-d motions, the ftftl time centro] piracy wcnild Iiave to be extended. 
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The languages, IAVF,, MINI, AL, VAL, and AML arc well within the nun Id of 
Lraditional procedural languages, both in syntax and the sermonties of =dl cxctfjt a 
ftw of their operations. The next three languages we consider have departed from 
the main-line oF computer programming languages in more significant ways, 

4.2,7. TEACH 1975- - I9T& 

The TEACH language [liuoff 7EI, 80] was developed as part of the PACS system 
at Rendix Corporation. The PACE system addressed two important issnes that have 
received Little attention in other robot programming systems: the issue of parallel 
execution of multiple tasks with multiple devices, including a variety of sensors; 
and the issue of defining robot-indepen dent programs- In addressing these issues 
TEACH introduced several Scciy innovations; among these were: 

1. Piograms are composed of partially ordered sequence of statements that 
can be executed sequentially or in parallel. 

2. The system supports very flexible mapping between the logLcal devices, 
e.g., robots and Fixtures, specified in the program! and the physical devices 
that carry them out, 

3. All motions are specified relative to local coordinate Frames, id as to enable 
simple re-lneatiou of the motion sequence. 

These features are especially important in the context of systems with multiple 
roboth and sensors, which art likely to be common in future applications. Few 
at tempts have been made to deal with the organisation and coordination problems 
of complex tasks with multiple devices, not all of them robots. Uuoff jSG] reports 
that even tlm facilities or TEACH proved inadequate in coping with very complex 
applications and argues fen- the use of model-hased programming tools., 

4,2, &- PAL 1978-prescnL 

PAL [Takase, Paul, and Berg 70] is very different in conception from the 
languages we have considered thus far, PAL programs consist- primarily of a sequence- 
uf homogeneous coordinate equations involving the locations of objects and of the 
robot's end-effector. Some nT the transforms in these equation^ c.g., those specifying 
the relative location of a feature to an object’s frame, are defined explicitly in the 
program. Other coordinate frames arc defined implicitly by the equations; leading 
the robot through an execution of the task establishes relations among these frames, 
Solving for the implicitly defined frames completes the program. 

PAL programs manipulate basic coordinate frames that define the position of 
hey robot features: l represents the base of the robot relative to the world, 16 
represents the end of the sixth (last] robot link relative to Z, and E represents the 
position of the cud-effector tool relative to T6. Motions of the tool with respect to 
the robot base are accomplished by specifying the value of Z + T6 + E f where + 
indicates composition of transforms. So, for example, t + T6 + £ = CAM + BKT + 
CliASP specifics that the end-effector should be placed at the grasp position on the 
bracket whose position is known relative to a camera, as discussed in Section 3.2. 
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The MOV <eip> command in PAL indicates that the 'generalized” robot too] 
fraTcjc, ARM * TDL, ia to he moved to <exp>, For simple motions of the end-effector 
relative to the robot base, ARM is 2 * T6 and TQL is. E. We can rewrite ARM to indicate 
that the motion happens relative to another object, e.g , the example above can be 
rewritten to be 

- BKT - CAM * Z * T& + E = GRASP 
in ibis case ARM can he net to the transform expression 

- BKT - CAM + Z + T6 

MOV GRASP will then indicate that the end-effector is Lo be placed on the grasp 
Frame of the bracket, as determined by Lhc camera. Similarly, placing the pin in 
the bracket’s hole can be viewed as redefining the tool frame of the robot to be at 
the hole. This can be expressed as 

- FIXTURE + Z + T6 + E - GRASP * HOLE * PIN 
By setting ARM. to * FIXTURE * z + T6 and TQL to E - GRASP * HOLE, MOV PIN will 
have the desired effect- GT course, the purpose of setting ARM and TOL is to simplify 
the exoression of related (nations in the same coordinate frame. 

PAL is still under development; the system described in [Takase, Paul, and Berg 
70| deals only with position data obtained from the user rather than the robot. Much 
of the development of PAL has been devoted to the natural use of guiding to define 
the coordinate frames, Extensions to this systems to deal with sensory information 
are suggested in |Paul SI], The bask idea is that sensory information serves to 
define the actual value of some coordinate frame in the coordinate equations. 

■4.2.9. MCL IDT9 - present 

MCI (McDonnell Douglas SO] is an extension of the APT language for 
Numerically Controlled machining to encompass robot control, including the 
following capabilities: 

1, data types, e.g., strings, booleans, reals, and frames; 

2, control structures for conditional execution, iterative execution, and 
multi-processing.; 

3, real-time input and output; 

4, vision interface, including the ability to define a shape to be located in 
the visual field. 

Extending APT provides some ease of interfacing with existing machining facilities 
i n clud ing i n terl'accs to exi stii i g geo metric d aiab ase s . By re tai ni n g APT compatibi l i ty, 
MCL can also hope to draw on the existing body oT skilled APT part programmers. 
On the other hand, the APT syntax, which was designed nearly 30 years ago, is 
not likely to gain wide acceptance outside of the NC-machining community, 

•4,2.10. Addition a! systems 

Many other robot language systems are reported in the literature, among these 


are: 
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1 . ML |Will and CrusSEnan TS] is a low-3evc) robot, language developed ai, IBM, 
with operations comparable to those of a computer assembly language. 

The motion commands specified joint motions for an (almost! cartesian 
robot. The language provided support for guarded moves by means of 
SENSOR commands that enabled sensor monitors; when a monitor was 
activated by a sensor value duLside of the specified range, all active motions 
were terminated, ML. supported two parallel robot tasks and provided for 
simple synchronisation between the tasks. 

2. EMILY [Evans, Garnet^ and Grossman 76', was an off-line assembler for 
the ML language. It raised the syntax of ML to a level comparable to 
FORTRAN. 

3. maPLE [Darranger and Blasgen 75] was an interpreted AL-like language, 
also developed at IBM. The actual manipulation operations were carried 
out by using the capabilities of the ML sysicm described earlier. MAPLE 
never received signiHcant use. 

4. si CL A 'Salmon 78], developed at Olivetti for the SIGMA robots, supports 
a basic set of joint motion instructions, testing of binary signals, and 
conditional tests. It is comparable tu the ML language in syntactic level. 
SIGLA supports pseudo-parallel execution or multiple tasks and some 
simple force-control. 

5. MAL [Gmi, et al. 79], developed at Milan Polytechnic, Italy, is a BASIC-like 
language for controlling multiple cartesian robots. The language supports 
multiple tasks arid task synchronisation by mean? of semaphores. 

6. LAMA'S [Falck and Parent EOjj, developed at I HI A, France, is a VAL-like 
language with support Tor on-line computations, for arrays, and for 
pseudo-parade I execution of tasks. 

7. LM jLatombe and Maser Si], developed at I MAG, Grenoble, France, is 
a language that provides most of Lhc manipulation facilities of AL in 
a mini-computer implementation, LM also supports affrxment, but not 
mult]-proccssing. LM is being used as the programming language for a 
recently announced industrial robot produced by Sconsi, Inc., 

3. RAIL [Franklin and Vamlerbrug 32], developed at AUTOMATED Snc- 
KAIL include? a large subset of PASCAL; it supports computations on 
a variety of data types, as well as providing high-level program control 
mechanism?- HAIL provides interfaces to binary vision and robot welding 
systems. The language has a flexible way of defining and accessing mput 
or output lines, either as single or multiple bit. numbers. HAIL statement? 
are translated into an intermediate representation which can be executed 
efficiently while enabling interactive debugging. RAIL is syntactically more 
sophisticated than VAL; it is comparable bn AML and LM. EiAlL does not 
support multi-processing or affixment. 

This is not a complete fist, new languages arc being developed every year, but it is 
representative of the state of the art, 
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4,3. Task-lev el programming 

Fiobot-level language describe tasks by carefully jipec.tfying the robot actions 
needed to carry it out. The goal or (asfc-fevel program ruing .HystcsnE [Park 77], 
on the other hand, is to enable task speciFj cation to be ill terms of operations an 
the: oijecis in the task. The peg-iti-hote task, for example, would be described as: 
INSERT teg in HOLE, instead or the sequence of robot inotitms needed to accomplish 
Lite insertion. 

A task planner transforms the task-level specifications into robots level 
specifications. To do this transformation, Urn. task planner must have a description 
of the objects being manipulated, the task environment d the robot carrying out 
the task, the initial state of the environment, and the desired final state, The 
output of the task planner is a robot-level program to achieve the desired final 
state when executed in the specified initial state. If the synthesized program is to 
reliably achieve its goal, the planner must take advantage of any capabilities for 
compliant motion, guarded motion, and error checking. Hence the Lank planner 
must synthesize a sensor-based robot-level program. 

Task-level programming is still a subject oF research; many unsolved problems 
remain. The approach, however , is a natural outgrowth of ongoing research and 
development in CAD/CAM and Jn artificial intelligence, 

Task planning cars he divided into three phases, modeling, task specification, 
and rohnL program synthesis. These phases are not computationally independent, 
but they provide a convenient conceptual division of the problem, 

■1.3.1. World Modeling 

The world model for a task must contain the Following information; 

1. geometric descriptions of all objects and robots in the task environment; 

2. physical description of all objects, e.g,, mass and inertia; 

3. kinematic descriptions of ali linkages; 

4. descriptions of robot characteristics, e.g., joint limits, acceleration bounds, 

and sensor capabilities, 

Models of task slates also must include the positions or all objects and linkages in 
the world model. Moreover, the model must specify the uncertainty associated with 
each of the positions. The role that each of these items plays in the synthesis of 
robot programs will be discussed in the remainder of the section- But first, we will 
explore the nature of each of the descriptions and how they may be obtained. 

The geometric description of objects is the principal component oT the world 
model- The major sources of geometric models are computer-aided design (CAD) 
systems, although computer vision may eventually become a major source of models 
|brady 82], There are three major types of commercial CAD systems, diiTEring on 
their representations of solid objects: 

1. line - objects are represented by the lines and curves needed to draw 

them. 
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Figure G, Models phuuuec! by wl operations an primitive volumes 
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2 . surface - objects are represented as a set of surfaces, and 

3. solid - objects arc represented as combinations of primitive solids. 

Line systems and some surface systems do noL represent all the geometric information 
needed far task planning. A list of edge descriptions, for example, is not sufficient to 
describe a unique polyhedron, e.g., [Markowsky and Wesley fifl]. In general, a solid 
modeling system is required to obtain a complete description, In solid modelers., 
models are constructed by performing set operations on a few types of primitive 
volumes, The objects depicted in Figure 6, for example, can be described as the 
union of two solid cylinders A and B r a solid cube and a hollow cylinder D- The 
descriptions of the primitive and compound objects vary greatly among existing 
systems- For surveys of geometric mod ding systems, see jBraid 78, Baer, Eastman, 
and Fenrioi] 79, Rcquicha 80j- 

The legal motions of an object are constrained by Lhe presence of other objects 
.ii the ■;>r.virnomerit and the form of t-he constraints depend in detail on the shapes 
of the objects. This is the fundamental reason why a task planner needs geometric 
descriptions of objects. There are additional constraints on motion imposed by 
the kinematic structure of the robot itself. If the robot is turning a crank or 
opening a valve, then the kinematics of the crank and the valve impose additional 
restrictions on the robot's motion. The kinematic models provide the task planner 
with the information required to plan robot motions that are consistent with 
external constraints. Examples of kinematic models and their use in planning robot 
motions can bo found in [Mason 611, 

The bulk of the information m a world model remains unchanged tlirougbout 
the execution of a task. The kinematic descriptions of linkages are an exception, 
however, As a result of the robot's operation, new linkages may be created and old 
linkages destroyed. For example, inserting a pin into a bole creates a new linkage 
with one rotational and one translational degree of freedom. Similarly, the effect of 
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inserting the piri might be Ln restrict the motion of one plate relative to another, 
thus removing one degree! of freedom from a previously existing linkage. The task 
jilanr.tr must be appraised of Lhasa changes, either by having the user specify 
linkage changes with each new task state, or by having the planner deduce the new 
linkages from the task state description. 

] E] planning robot operations, many of the physical characteristics or objects 
play important roles, The mass and inertia of parts, for example, will determine 
how fast they can be moved or how much force can be applied to them before 
they fall over. Also, the coefficient nT friction between a peg and a hole affects the 
jamming conditions during insertion (see, e.g., [Ohwovoriole and Roth 81, Whitney 
s2]). Hence, the world model must include a description of these characteristics. 

The feasible operations of a robot are not sufficiently characterised by its 
geometrical, kinernatical, and physical descriptions, We have repeatedly stressed 
the importance of a robot's sensing capabilities; touch, force, and vision. For 
task planning purposes, vision allows obtaining the position or an object to some 
specified accuracy, at execution time- Farce sensing allows performing guarded and 
compliant motions- Touch information could serve in both capacities, but its use 
remains largely unexplored [Hannon B2]. In addition to sensing, there are many 
individual characteristics of robots that must be described in the world mode]: 
velocity and acceleration bounds, positioning accuracy of each of the joints, and 
workspace bounds, for example. 

Much of the complexity in a world model arises from modeling; the robot, which 
ts done once. Geometric, kinematic, and physical models or other objects must 
be provided Tar cadi new task, however. The underlying assumption in task-level 
langauges is that this information would have been developed as part of the design 
of these objects. IT this assumption dues not hold, the modeling effort required for 
a task-level specification, using current modeling methods, might dwarf the effort- 
needed to generate a robot-level program to carry out the task. 

■1.3.2. Task Specification 

Tasks can be specified to the task planner as a sequence of models of the 
world state at several step? during execution of the task. An assembly of several 
parts, For example, might be specified by a sequence of models as each part is 
added to the assembly. Figure 7 illustrates one possible sequence of models for a 
simple task. All of the models in the L-ask specification share the descriptions of 
the robot’s environment and or the objects being manipulated; the steps in the 
sequence differ only in the positions of the objects. Hence, a task specification h, 
at first approximation, a model of Lhc robot's world together with a sequence of 
change? in the positions of the model components. 

A model state ls given by the positions or all the objects in the environment. 
i hi nee, tasks may be defined, in principle, by sequences of states of the world 
model. The sequence of model sLates needed to Fully specify a task depends on 
the capabilities of the task planner. The ultimate Lask planner might need only 
a description of the initial and final state of the task. This has been the goal of 
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Figure 7. Task lJestriptaOu as a sequence of model states. 



much of the research on automatic problem solving within artificial intelligcncE 
[see, e.g,, [Nilsson SO])- These problem solving systems typically do not specify the 
detailed robot motions necessary to achieve an operation 8 . These systems typically 
produce a plan where the primitive commands are of the form: P1CKUP{A) 
and MQVETO{p) without specifying the robot path or any sensory operations, 
In contrast to these systems, task planners need significant information about 
intermediate stales, but they can be expected to produce a much more detailed 
robot program. 

The positions needed to specify a model state are essentially similar to those 
needed to speed Fy positions La robot-level systems. The op Lion of using the robot to 
specify posiLions is not open, however. The uLher techniques described in Section 
3,2 are still applicable. The use of symbolic spatial relationships is particularly 
attractive for high-level task specifications. 

We have indicated chat mode] state? are simply sets oF positions and task 
specifications are sequences of models. Therefore, given, a method such as symbolic 
spatial relationships for specifying positions., we should be able to specify tasks. 
This approach has several important limitations, however. We noted earlier that 
a set of positions may overspecify a state. A typical example [Finkcl 7fi) of this 
difficulty arises with symmetric objccLs, For example a round peg in a round hole, 
The specific, orientation of the peg around its axis given in a model is irrelevant to 
the task. This problem can be solved hy treating the symbolic spatial relationships 
them set vet as specifying the state, since these relationships can express families of 


The merit prominent exeepltan is STRIPS [Nil*Kin Cfl], whkh ijvr-l uded medium mus to ■cirrjr 
Out Lti' plai] in Un 1 - real world 
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positions. Another, more fundamental (imitation, is that geometric and kinematic 
models of an operation's final stats arc not always a complete specification of the 
desired operation. One example of this is the need to specify how hard, to tighten 
a bolt during m assembly. In general, a complete description or a task may need 
to include parameters of the operations used to reach one task state horn another. 

The alternative to Lank specification by a sequence of model states is specification 
by a sequence of operations. Thus, instead of building a model of an object in 
its desired position* we can describe the operation by which it can be achieved. 
The desnripljon should stilt be object-oriented, not roboi-oricnLed- for exam pie, 
the target torque for tightening a holt should be specified relative to the bolt and 
not the robot joints;. Operations will also include a goal statement involving spatial 
relationships between objects. The spatial relationships given in the goal nut only 
specify positions, they also indicate the physical relationships between objects that 
should be achieved by the operation Specifying that two surface are Against each 
other, for example, should produce a compliant motion that moves until the contact 
is actually detected, not a motion to the position where contact is supposed to 
occur. For these reasons, Existing proposals for task-level programming languages 
have adopted an operation-centered approach to task specification [Usbcnuan and 
Wesley T7, l.osano-Peres 76j. 

The task specified as a sequence of model states in Figure 7 can be specified 
by the following symbolic operations* assuming that Liu: model includes names Tor 
object* atnl object features: 

FLACE BEARING! so (SHAFT FITS HEARIHG1.HM.E) ANC 

CHEWING l.BDTTQU AGAINST SHAFT.LIr) 

FLAG! SFACEH SO (SHAFT FITE SPACES.. HOLl£> AMP 

(SPACER 0OITC1W AGAINST EEAHlNCl. TOPI 

PLACE REARIHC2 SO (SHAFT FITS BEAMNC2.HOLE) AND 

(HEARINGS.BOTTOM AGAINST SPACER . TDlP) 

PLACE YTA5HER SO (SHAFT FITS WASHER. HOLE.) AND 

(UAS'HFjR.nDTrDll ASA 1 If ST BEARINGS. TOP) 

SCHEK-IN NUT ON SHAFT TG (TfifUiUE = 10) 

The first step in the task planning process is. transforming the symbolic spatial 
relationships among object features in the SO clauses to equations on the position 
parameters of objects in the model- These equations must then be simplified as far 
as possible to determine the Legal ranges of positions of all objects |Ambler and 
Fopplest.one 7b, PoppJestonc, Ambler, and I kilos SO, Taylor 7b], The symbolic form 
of the relationships is used during program synthesis also- 

We have mentioned that the actual positions of objects at task execution 
time will differ from those in the model; among the principal sources of error arc 
part variation, robot position errors, Jind modeling errors. Robot programs must 
tolerate sonic degree of uncertainty if they are to be useful, but programs that 


Ii:u i ii-Li 


ilHilmL J'rriir^imrnni, 


guarantee success under worst case rrmr assumptions. art difficult to write and slow 
lu execute. Hence, the task pi an tier must use expectations on the uncertainty to 
choose motion and sensing strategies that are efficient and robust 'In quo 14). If the 
uncertainly is Lao large to guarantee success, then additional sensory capabilities 
or fixtures may be used to limit the uncertainty [[hooks 82b* Taylor 7fi|. For this 
reason, estimated uncertainties are a key part of task specification. 

It is not desirable to specify uncertainties numerically Tor each position or 
each state. For rigid objects, a more attractive alternative is to specify the initial 
uncertainty of each object and use the task planner La update the uncertainty as 
operations are peiformed, Fur linkages, information on uncertainty at each of the 
joints can be used to estimate the position uncertainty of each of the links and of 
grasped objects [Brooks fil, Taylor 76]. 

4.3.fL He but Program Synthesis 

The synthesis of a robot program from a task specification is the crucial 
phase of task planning. The major steps involved in tiiis phase are grasp planning, 
motion planning* and plan checking. The output of the synthesis phase is a 
program composed of grasp commands, several kinds of motion specifications* 
sensor commands, and error tests, This program is in a robot-lfivnl language for a 
particular robot and is suitable for repeated execution without re-pi aiming. 

Grasping is a key operation in robot programs since it affects all subsequent 
motions. The grasp planner must choose where to grasp objects so that no collisions 
will result when grasping or moving them [Laugier Si, Lozano-Peres 76, 81, Mathur 
74, Wingham 77J. In addition, the grasp planner must choose grasp positions so 
that the grasped objects arc ztuble in the gripper [Brady 82, Hanafusa and Asad a 
7G, Paul 72|. In particular, the grasp must be able to withstand the forces generated 
during motion and contact with other objects. Furthermore, the grasp operation 
should be planned so that it reduces, or at least does not increase, any uncertainly 
in the position of the object to be grasped [Mason 82 : , 

Once the object is grasped, the task planner must synthesise motions that will 
achieve the desired goal of the operation reliably. We have seen that robot programs 
involve three basic kinds of motions: free, guarded, and compliant. Motions during 
an assembly operation, tor example, may have up to four sub motions: a guarded 
departure from tire current position* a free? motion towards the destination position 
of the task step* a guarded approach Lo contact at the destination* and a compliant 
motion l.n achieve the goal position. 

During free motion, the principal goal is to reach the destination without 
collision; therefore, planning fr*E motions is a. problem in obstacle avoid ante. Many 
obstacle-avoidance algorithms exist but none: of Litem are both general and efficient. 
The type of algorithm that lias received the most attention are those that build arc 
explicit description of the constraints on motion and search for connected regions 
satisfying those constraints; see, "Brooks 82a, Brooks and Loaano-Percv 82, 
Kuntae and Schill 82, Loaano-Pirec SI* Loaano-P^res and Wesley 79, Schwarts and 
fjharir 81* 82, Udupa 77] - A simple example of this kind of technique is illustrated in 
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Figure 8. Two Fqui valent Obstacle Avoidance Problems 



Figure 8 - A moving polygon A = UMi, with distinguished point i> A , must translate 
amo]]g obstadt polygons H r This problem is equivalent to the problem in which 
U 4 translates among transformed objects C t ,j- bach Ccj represents the forbidden 
positions of if* arising because of potential collisions between Ai and By. Any curve 
that does not overlap any of the Ci i} is a safe path for A among the B Jr Extensions 
of this approach can be used to plan the paths of cartesian robots |Lo 2 anQ-Perez 
SI, hasano-PereE and Wesley 79[, 

Compliant motions are designed to maintain contad among objects even in 
the presence of uncertainty in the location of the object^ see [Mason SSj for a 
review, The basic idea is that the robot can only control its position along the 
tangent to a surface 9 without violating the constraints imposed by the surface. In 
the direction normal to the surface, the robot can only control forces if it is to 
guarantee contact with the surface. The planning of compliant motions therefore 
requires models that enable one to deduce the directions which require force control 
and those that require position control. This planning is most complicated when 
the robot interacts with other mechanisms [Mason 81], 

Compliant motion* assume that the robot is already in contact with an object.; 
guarded motions arc used to achieve (he Initial contact with an object [Will and 
Grossman 15]. A guarded motion in the presence of uncertainty, however, docs 
not allow the program to determine completely the relative position of the objects, 
several possibilities may be possible as a result of the motion l^see Figure 9), A 
strategy, com posed of compliant motions, guarded motions, mid sensing-, must be 
synthesized to reli&hly achieve the specified goal. In particular, for the example in 
Figure 9, the strategy must guarantee that the desired final state is achieved no 


“Surface in dm context actually means a csn/ljjwra(i'an spate surfs**:, i-fi-, ibe manifold e£ position 
and orientation parameters! that ensure a particular kind oT contact between two cbjctti, tee 
[Losi.-iiwb-rtfrcs 81, Meson Si) 
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Figure 9+ Ambiguous I Usui 1$ of a Guarded Motitui under L"n certainty 



matter which of the possible states actually is reached, Brooks 82b, Latombe 82, 
Lozano-Peres 76, Lcaano-Penes, Taylor, and. Mason 82, Taylor 76], 

Most of the difficulty in doing n]otion synthesis sLmns from the need to operate 
under uncertainty in the positions of the objects and of the robot. These individual 
uncertainties can be modeled and their combined Effect on positions computed, 
The requirements for successful, completion of task steps can bn used to choose 
the strategy for execution, c.g., an insertion with large clearance may be achieved 
by a positioning motion, while one with little clearance might require a guarded 
motion to find the surface followed by a compliant motion | Pranks 82b p Taylor 
7G]. In general, the uncertainty in the position of objects may be too large to 
guarantee that some motion plan will succeed. Eu iIlgse cases, non-contact sensing 
such as vision may be used at run-time to reduce the uncertainty. The task planner 
must decide when such information is likely to be useful, given that the sensory 
information also will he subject to error. This phase or task planning has been 
dubbed plan checkin?; it is treated in detail by [Brooks 82b|. 

Task planning, as described above, assumes Lhat the actual state of the world 
will differ from the world model, but only within known bounds. This will not 
always be the case however; objects may J>c outside the bounds of estimated 
uncertainty, objects may be of the wrong type, or objects may be absent altogether. 
In these cases and many others, the synthesized programs will not have the expected 
result; the synthesized program should detect the Failure and cither correct it or 
discontinue the operation. Error detection will avoid possible damage to the robot 
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an,d other parts or the Environment. Hence, an import-ant part or robot- program 
synthesis should he the inclusion of sensory tests for error detection. Error detection 
and correction in mho', programs is a very difficult profilem, but one for which very 
little research is available [Brooks 82b, Gini, Gini, and Somatvico 81 ^ Losano-Pcres 
76j. 

4.3.1, las It-level systems 

A number of task-level language systems have bean proposed, but no complete 
system has been implemented. We saw above that many fundamental problems 
remain unsolved in thin- area; languages have served primarily as a focus of research, 
rather than as usable systems. 

The KQVE-rNSTMCE system (Feldman, et aJ. 71] was the first of the task-level 
system proposals. A subset of this proposal was implemented [Paul 72], namely, a 
program that chose stable grasping positions on polyhedra and planned a motion 
to aproach and move the object. The planning did not involve obstacle avoidance 
(except for the table surface) or the planning of sensory operations. 

The initial definition of At fFinket, ct aL 74] called for the ability te specify 
modds in AL and to allow specification of operations in terms of these models. This 
has been the subject of some research [Binford 79, Taylor 76], but the results have 
i 1: 1 - ,-m incorporated 11 .if: the existing AL system. Smur atldiiimial work wivljm the 
context of Stanford’s Acronym system [Brooks fll] has dealt with planning grasp 
positions [Binford 73[, but AL has been viewed as the target language rather than 
the user language. 

Taylor 76] disc iiHscs an approach to the synthesis uf sensor-based AL programs 
from task-hwH specifications, Taylor's method relies on representing prototypical 
motion strategies for particular tasks as parameterized robot programs, known as 
procedure skeletons. A skeleton has all the motions, error tests, and computations 
needed to carry out a task, but many of the parameters needed! tu specify motions 
and tests remain to be specified. The applicability of a particular skeleton to a task 
depends on the presence of certain features in the mode! and the values of parameters 
such as clearances and uncertainties. Choices among alternative strategics lor a 
single operation are made by first computing the values of a get of parameter* 
specific to the task, such as the magnitude of uncertainty region for the peg in 
peg-in-hole insertion, and ttum using these parameters to choose the :, best" f e.g,, 
Fastest, strategy. Having- chosen a strategy, the planner computes the additional 
parameters needed to specify the strategy motions, such as grasp positions and 
approach positions. A program is produced by inserting tlmac parameters into the 
procedure skeleton that implements the chosen strategy. 

The approach to strategy synthesis based on procedure skeletons assurors that 
task geometry lor common sub-tasks is predictable and can be divided into a 
manageable number of classes each requiring a different skeleton. This assumption 
is needed because the sequence oF motions in the skeleton will only be consistent 
with a particular class of geometries. The assumption doc-a not seem to be true 
in general. As an example, consider the tasks shown in Figure 10. A program for 


H i-.-i in t 


Repot l 1 roKracn.niLnjs 


Figure 10, Similar Leg-in-Hole Tanks Which Require Different Strategies 



task A could perhaps be used io accomplish tasks D and O, but It could not be 
guaranteed Lp ■work reliably. In pxrLicimir, the presence of additional surfaces in 
tasks E and C may generate unexpected contacts, leading to failures. This approach 
contrasts to an approach which derives the strategy directly from consideration of 
the task description [Lpaano-PcrcM, Taylor, and Mason R2|. In advanced system*, 
both types of approaches are likely to play a role. 

The LAMA system was designed at MIT |Lcizano-P-ilrc 2 76, Losano-Ftrea 
and Winston 77] as a task-level language, but only partially implemented, LAM.A 
formulated the relationship of task specification, nhstack avoidance, grasping, 
she Is ton-based strategy synthesis, and error detection within one system. More 
recent work at MIT has explored issues in task planning in more detail outside of the 
cutltexL of any particular system |E1 rooks 82a, 82b, LcrtAno-FertsE 81, Lu^arm-Pcrc*, 
Taylor, and Mason 82 h Mason 81, 82]. 

AUTOPASS, at IBM [Lieberman and Wesley 77], defined the syntax and Bemantiee 
of a task-level language and an approach to Its implementation. A subset of the 
most general operation, the PLACE statement, was implemented, The major part of 
the implementation effort focused on a method for planning collision-free paths for 
cartesian robots among polyhedral obstacles [Losano-Pfrea and Wesley 79, Wesley, 
et al, SO], 

RAPT jPopplestone, Ambler, and Bellos 7B| Is an implemented system for 
transforming symbolic specifications of geometric goals, together with a program 
which specifies: the directions of the motions but out their length, into a sequence of 
end effector positions. ftAET's emphasis has been primarily on task specification; it 
dues not deal with obstacle-avoidance, automatic grasping, or sensory operations. 

Some robot-level language systems have proposed extensions to allow some 
task-level specifications. LM-GEO (Maser 82] is an implemented extension to LX 
[Latom.bc and Maser 811 which incorporates symbolic specifications of destinations. 
The specification of ROfO jWeck and ZuhlkeSl] include* the ability to automatically 
plan collision-free motions and to generate programs that use sensory information 
available during execution, A full-blown RC1BEX, including these capabilities, has 
not been implemented- 
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The deficiencies of exi^t-Lne methods Tor geometric reasoning arid sensory 
planning have prevented implementation of a complete task-level robot programming 
system. There has, however, been significant progress towards solving the basic 
problems in task planning;. see [Loiana-P4rea fi3] for a review. 
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5. Discussion and Conclusions 


Existing robot programming systems have focused primarily on the specification 
of sequences of robot configurstfonSr This is only a small; aspect of robot 
programming, however. The central problem nf robot programming is that of 
specifying robot operations so that they tan operate reliably in the presence of 
uncertainty and error. This has long been recognised in research jabs, but until 
very recently has found little acceptance m industrial situations. Some key reasons 
for this difference hi viewpoint are: 

1. The lack or reliable and affordable sensors, especially those already 
integrated into the control and programming systems of a robot. 

2, Existing techniques for sensory processing have tended to be slow when 
compared to mechanical means of reducing uncertainty. 

Both of these problems are receiving significant attention today. When they are 
effectively overcome, the need Tor gond robot programming tools will bn acute. 

The main goal of this paper has been to assess the state-of-ths- art in robot 
programming compared with the requirements or sophisticated robot Lasks. Our 
conclusion is that ail or the existing'robot systems fall short of meeting the 
requirements we can identify today. 

The crucial problem in the development of robot programming languages is 
our lack of understanding of the basic issues in robot programming. The question 
of what basic set of operations a robot system should support remains unanswered. 
Initially, the only operation available was joint motion. More recently, cartesian 
motion, sensing and, especially, compliance have been recognised as important 
capabilities for robot systems. In future systems, a whole range of additional 
operations and capabilities are to he expected: 

1. Increasing mfeprohem of sensing and moh’om More efficient and 
complete implementations of compliant motions are a key priority. 

2p Complete object models as a source of data for sensor interfaces and 
trajectory planning; Existing partial models of objects are inadequate for 
most sensing tasks; they are also limited as & source oT path constraints. 
Surface and volume models, together with appropriate computational 
tools, should also open the way for more natural and concise robot 
programs, 

ff. Versatile trajectory specifications'. Current systems overspecify trajec* 
toriesand ignore dynamic constraints on motion. Furthemore, they severely 
restrict the vocabulary of path shapes available to UiCffi. A mechanism 
such as functionally-defined motion can make it easy to increase the 
repertoire of trajectories available to the user. 

4. Coordination of multiple parallel tasks: Current robot systems have 
almost completely ignored thtR problem, but increasing use of robots with 
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more than six degree&-of-fFWdom, grippers with twelve or more degrees- 
of-freedom, multiple special-purpose robots with two qr three degrees- 
of-freedom, and multiple sensors will make the need For coordination 
mechanisms more severe. 

5. The 1/0 r control, and JifnefiTonfffoijon capabilities of general-purpose 
computer programming languages: A key problem in the development 
of robot languages has been the reluctance,, on the part of users and 
researchers alike, to accept, that a robot programming language must be 
a sophisticated computer language. The evidence seems. u> point to the 
conclusion that a robot language should he a fu-perset of an established 
computer programming language, not a subset. 

These developments should be matched with continuing L-HortE at raising the level 
of robot programming towards (.he (ask-level. By automating many of the routine 
programming functions, m tan simplify the programming process and thereby 
expand the range or applications available to robot systems. 

One problem that has plagued robot programming research has been the 
significant "barriers to entry 1 * to experimental research in robot programming. 
Because robot control systems on available robots are designed to be stand-alone, 
every research group has to re-Implement a robot control system From the ground up. 
This is a difficult and expensive ope ration. It is to be hoped that commercial robots 
of the future will be designed with a view towards interfacing to other computers, 
r;-:l than =■>■: stand [done ?y stems. This should greatly u iir.iil.-uc drvd opuient ai 
the sophisticated robot programming systems that we will surely need in the future. 
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